GNOME Bugzilla – Bug 128554
Search and replace dialog shouldn't hide currently highlighted match
Last modified: 2014-07-07 10:40:52 UTC
When the search pattern is found in text underneath the Find dialog itself, the matched text is highlighted, though not visible. A solution to this problem would be to move the Find dialog automatically up or down, depending on where there is some space, so that it doesn't hide the currenlty highlighted match. I think that Notepad or Wordpad in Windows XP already do something like this.
Maybe it's a better idea to scroll the text so that it is not under the find dialog anymore. I also notice that a match is sometimes just below the end of the part of the file you are viewing
Moving the dialog may have some a11y problems (I may be wrong). Scrolling the text may be impossible in some cases. I don't see a valid solution for this issue. BTW, gedit 2.13.x supports incremental search (use Ctrl+K accellerator). Incremental search greatly mitigates this problem.
What happened to the search tab on the right of the screen? It's been a while in the new_mdi branch. Incremental search doesn't solve the problem for replace
We were not satisfied with the sidepane: after using it for a while it turned out to have many drawbacks some fixable some not. Replace in particular is not well suited for a bar/pane and doesn't play well with incremental matching. We felt it was best to keep the dialog given, among other things, that 1) we really wanted to have new_mdi ready for 2.14 and 2) we don't want an ever changing UI, so we prefer to keep the current UI than changing it now, then changing it again in 2.15 etc. Btw, new_mdi is now on HEAD and the 2.13.0 and 2.13.1 tarballs are based on the new code.
Thanks for the explanation. So I guess the only remaining option is to scroll the text such that the highlighted text is always visible
I hope you will consider a bottom pane as discussed in bug #153641?
*** Bug 534221 has been marked as a duplicate of this bug. ***
Still happens in 3.2.
Are you still seeing this with more recent versions of gEdit? The find dialog has been migrated to a find bar in the top right corner, so it shouldn't hide any matched.
(In reply to comment #9) > Are you still seeing this with more recent versions of gEdit? The find dialog > has been migrated to a find bar in the top right corner, so it shouldn't hide > any matched. Yes. Not necessarily with the find dialog, but the find & replace dialog.
Created attachment 276203 [details] Quick mockup of search+replace popup Ah, yes, you're right, the replace dialog is still a traditional dialog (in the meantime I have checked and the search popup scrolls the page if the match is underneath the popup, so that one doesn't have this problem) Maybe the replace dialog should be migrated to the search popup too: Here are my ideas: * Ctrl+F brings up the search popup with one entry only, for searching * Ctrl+H brings up the search popup with two entries, one for search and another one for replace with text, with next/previous after the search, just like in the current search popup, and replace/replace all buttons after the replace entry. A quick mockup (of course that could be styled and better icons would be even better, these are just examples)
Nice, but why Ctrl+H? Could we use Ctrl+R instead?
As far as a dialog window is used, this bug cannot really be fixed. And the dialog window is useful. It is not an incremental search, you apply the search only when a button is pressed. So you can have different searches in different documents. With the search-as-you-type, you can not do that. So I think this is a wontfix.