In response to Kate in KDE 4.8, there was this reply on reddit:
Does this mean the stupid search/replace functionality has finally been fixed?
Once the search/replace marks/colors text there’s no way to clear it so when you’re replacing keywords the last one will be permanently marked with background color unless you reload the file or search for something else… Infuriating.
It’s about the yellow / green background for search matches / replace items. But stating that you have to reload the file in order to remove the highlighting is completely wrong. If you dislike the persisting highlighting, just press ESC, and it is removed (yes, this is by design, and imho very useful).
There is a pretty good book called The pragmatic programmer, and one rule of thumb is
Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
How true! 🙂
That you had to publish this blog in order to “get the word out” about using Esc to clear the replacement highlight indicates how poorly implemented the feature is. There is _nowhere_ in the entire UI that makes one think pressing Esc would clear it.
Claiming that a feature is poorly implemented because just ONE use didn’t find it does not say anything in the first place.
It’s true that it is not obvious. However, what you state also doesn’t provide any constructive feedback: How would you implement it?
Hey,
I’m the OP of the comment you’re referencing. I was just informed about this entry.
I thought it was an oversight / bug because there’s no “Clear”-button on the replace menu at all.
What’s the UI term for the menu anyway? Pull-up menu? I guess “dialog” is the wrong word for it. *shrug*
Personally, I think that the replace menu should have a “Clear”-button (the menu seems to have room for one, on the same row with “Find All”), which you could use to clear it.
Alternatively, it would seem intuitive that if you close the replace menu from the red cross it would also clear the highlight, after all, “you’re done with the replacing” once you want to close it. You can minimize the menu with the green down arrow, so if you want to keep highlighting, it would make sense to just minimize it.
Gedit seems to have “persistent” highlighting as well, but the “Search” menu contains a “Clear Highlight” button. I don’t exactly remember how other programs do it.
Seems to me a solid and right solution:
Button “Clear Highlight” AND/OR auto clear highlight
If that’s not what is going to happen at least a message would inform the user that he/she can clear the highlight with Esc. Users should not have to learn the hotkey-list to perform actions.
On another note: I’m sure there are hundreds of other features most of the users are not aware of. This also doesn’t automatically imply that they are poorly implemented. 🙂
the key is the standard to abort actions, close dialogs etc from ages, it’s widely used as is in kde, I never had to think of what to use to remove the highlighting, my finger just knew what to do.
While I’ve my grasp with search and replace in kate (mainly the per file limitation) the polemic on this one is just …. <- put something here.
You can search & replace in all files with the “Search and Replace” tool view from KDE >= 4.8.
It’s not the same as search & replace in the panel, but does the job very well.
That this entry had to be published speaks to the people not smart enough familiarize themselves with an application outside of the immediate need time for it, but still arrogant enough to think they’re pretty damn smart. I ran into this problem as well, I’m no different than you or any of the other complainers- but I didn’t throw a fit. I put my energy drink down and took a few minutes to become more familiar with the system. I didn’t stupidly try to figure out an application’s functionality while under a deadline. Call MS for software like that, I’m sure they have a pricing model that you would be satisfied with.
I code a bit, but likely less than the complainers here, and yet I took awhile to compare many different editors across windows, bsd, and linux. I settled on Kate, and when I did, it was because I did my homework and knew it well.
People who find the time to complain in detail about the escape key functionality missing from documentation should take the same amount of time familiarizing themselves with the applications they use, or spend the same amount of time uninstalling them so they don’t waste any more of their time.
What babies.
the previous comment started “the Esc key” but with Esc in angular parentesis the blog software ate it
What’s intuitive for one isn’t intuitive for the other. Obviously pressing ‘esc’ in this case isn intuitive for everybody (I dont think I would have found it either), and in any case it’s not easily discoverable.
How about an option for the “highlight selection” extension that says “Stop highlighting searchs when a) the ‘esc’ key is pressed b) the search panel is closed” ? That way the feature would be slightly more discoverable, and it would be possible to turn it off for people who prefer a cleaner experience ?
Hiding the highlights when closing the search panel works. It even was implemented this way at some point.
However, there are users (including me) who search for text, and then use these highlights for quite some time to orient in the document or work successively on the highlights. Given the the search & replace panel requires quite a lot of space, it was implemented the way it is right now.
In others words: To hide the search / replace panel, you can hit ESC. If you do that and do not want the highlights, press ESC ESC. As the hand is already at the position, this should not be a problem at all…
The only real issue is that it is hard to discover. This is a valid criticism. 🙂
Btw, it is implemented here:
https://projects.kde.org/projects/kde/kde-baseapps/kate/repository/revisions/master/entry/part/view/kateviewinternal.cpp#L2125
1. ESC: hide code completion
2. ESC: if there is a panel (goto, search, command line, …) hide it
3. ESC: remove text selection
4. ESC: remove search/replace highlights
How does that interact with the VI mode?
Come ON! The panel does not take up THAT much space! I mean, it sounds really stupid that because some hard core users want to be able to keep the highlights while hiding the (rather small) search bar, the rest of us (casual users) have to suffer unintuitive behavior. Of course the highlights should disappear when you close the search bar, that’s what anyone would expect (can you really disagree, honestly?)! You could then have an extension that makes the highlights stay visible for those who want it.
Welcome to the borders of “coder decides”.
I agree with Tuukka. I use my desktop in a way ‘normal’ users would not understand at all. However, if I would write the code for it, the biggest misstake would be to write it the way I use it. It should be the way THE MAJORITY OF THE USERS want’s to use it.
I know it’s a little ‘problem’ cause not many people will notice. But small things like this makes KDE Software hard(er) to understand for ‘average users’.
I disagree, the best thing you can do is write for what you do.
Kile was obviously written by someone who writes a lot of LaTeX, Amarok 1 by people with large media collections. As soon as you lose that you end up with crap. It goes on.
The worst thing you can do is constantly implement what the noisy random people on the internet want. As soon as you do that you get massively bloated piles of crap that don’t suit anyone.
I like this feature and I like it even more now that I know how to quickly clear the higlighting with ESC 🙂
However, I use a dark color theme (white text on dark grey background) and I can’t find a way to change the highlight color… bright green is totally unreadable on white text.
Not really related : I’m not sure but I think I’ve seen some times ago a plugin in GIT related to dark themes and Kate (maybe to force a dark color for all the lists widget’s background or something like that ? But I may be wrong 🙂 )
well I can’t find this plugin anymore… maybe I was dreaming, or it was from another project (maybe KDevelop ?)…
Such a plugin doesn’t exist in Kate, I fear.
Thanks for sharing your thoughts above 🙂
I use a dark color theme as well and I dread having to use the find or replace feature since the highlighting makes everything I’m looking for completely unreadable. The green and yellow colors are actually coded directly in the source and there is no way to change it save compiling a custom Kate for yourself. I love Kate, but this drives me nuts.
It would be even greater to also highlight the search-results with little colored lines in the scroll-area like googe-chrome does. would that be possible?
The new “Search and Replace” plugin does that, yes 🙂 [but not the search panel in the view, should be rather easy to add, though]
To my mind using ‘esc’ for getting rid of highlighting is quite intuitive. I did discover it a while ago and it didn’t take long to figure it out. My mind went something like “so, I searched and replaced, and now some things are still highlighted by the search, so I’ll just close the search”, and that was it.
You have to ‘escape’ from an highlight. Says it all…… 😉
I also never discovered this feature, and hence was annoyed by the persistent highlighting quite a few times.
I think the only sensible thing usability-wise is to clear the highlighting once the search bar is closed.
For those presumably rare cases that someone indeed would want to keep the highlighting while continuing to edit the document, leaving the search bar open is not too much to ask.
I completely agree. I always start a new search to get rid of the highlighting.
I was just too lazy to create a bug report / look if one existed.
I like to think of myself as a good designer so here goes. (I’m not sure why I’m replying to this post in particular)
Main points:
It clearly is a bit of an issue as several people have fallen into the trap. I myself didn’t, I think I instinctively bash escape a lot. If more than one person make a mistake then it could do with changing. It also doesn’t mean you’ve done anything wrong, UI is an iterative process.
However, the main pro tip in UI; There is never a single “only sensible thing to do”! Any reply on this site saying “you should do XYZ” is bollucks and should be promptly ignored. It is simply the first thought of the person writing the reply. Chances are they haven’t thought it through either and you’ll just get a different problem.
The correct steps (IMHO):
– Identify the problem
“people often have highlighted character left on and are unsure of how to clear it”
– Work out why
It is different behaviour to other apps, relying on a keyboard process which isn’t totally apparent to all users.
However – this doesn’t completely cut it, are there any instances in KDE where this behaviour differs? Why would a user not instantly guess pressing escape?
– List possible solutions:
Overlay a message in the main UI, or when closing the list
Add a “clear selections” button
Deselect when closing find
Add a “clear selections escape” menu entry under Edit. Allows a user to clear them, and notice the handy shortcut for future.
Leave as is (still a perfectly viable option), but make sure it’s mentioned clearly in the manual and userbase.
+ Many other options I’ve not thought of.
When you’ve brainstormed a load of possible way on doing something, you might see something stands out.
“Why would a user not instantly guess pressing escape?”
Because escape is usually used to CLOSE a self-contained UI element (dialog window / message box / popup / menu / tool tip / etc.), not to REMOVE something from a document.
@Dominik: http://kate-editor.org/2011/12/21/on-being-wrong/
“What is your first reaction when someone points out a mistake in your code, a shortcoming in your design or questions your premise for a solution? Does your pulse quicken? Is a retort ready to be hurled? Does your voice rise? Do you feel besieged? Are you convinced you are being treated unfairly? These are all signs that you are suppressing fear and denying the possibility that you may be wrong. You may win the battle by browbeating your opponents at the table, but you’ve lost the war of gaining their respect. […] Anger and defensiveness are masks for insecurity, so watch out for them and focus on understanding the causes of your reaction than on the motives of your (perceived) opponents. Being wrong is inevitable; your colleagues are doing their jobs by questioning, probing and analyzing the design; are you doing yours by being open, receptive and flexible?”
Great article indeed 😉
I was waiting for this reply.
Changing it for KDE 4.8.0 is not a problem. But adding a button is not allowed because it introduces new strings to translate.
Other ways to include it mean introducing hidden features again.
“But adding a button is not allowed because it introduces new strings to translate.”
Also it would add unnecessary clutter.
“Other ways to include it mean introducing hidden features again.”
There’s nothing inherently evil about hidden features – especially if they target power-users – as long as they are “opt-in” features, which would only need to be activated if the user *wants* to do something special.
Long-time users can learn about such features over time from blogs or “Tips & Tricks” sections of websites/wikis and then use them on demand.
Troubles arise when typical users can easily get into an annoying/irritating situation they didn’t ask for, and the method to *opt-out* of it is a hidden feature.
I just asked KDE’s awesome translators to grant a string freeze exception so I can get this tidbit of info in the documentation included with 4.8. Hopefully that will help users find this a little easier. 🙂
In this case, you were quite fast with adding it to the documentation 🙂 I was thinking about changing the behavior for 4.8.0 as it seems the majority does not even find out how it works. Now that it is documented, changing it would lead to wrong documentation, which is also not optimal 😉
So the next time, let’s quickly discuss this before asking for an exception for the string freeze. 🙂
Sorry about that! This (rather long) discussion left me with the impression it wasn’t going to get changed for 4.8, and I did want to get it in quickly so there was still plenty of time to get it translated before 4.8 shipped.
You’re not thinking of getting rid of ESC though are you? I’m all for a button to help people find it easier, but IMHO a keyboard shortcut is a lot nicer for this (once you know about it ;-). I tend to CTRL+[F|R] into Find/Replace and never touch the mouse if I don’t have to.
I could add a checkbox “[ ] Keep highlighting” in the search&replace mode. A tooltip then could explain the ESC trick. But this is only possible for KDE 4.9, again due to string freeze.
I’m a bit surprised that nobody seems to have suggested that improving the documentation would probably be enough to satisfy the users.
The feature itself is good, but is-it described in the documentation?
My google search tend to make me believe that this isn’t the case, so this is clearly another case of incomplete features: the code is there but the documentation isn’t..