Well, this has been like this for ages in previous versions of gedit. See that to jump from one occurrence to another, you can use control+g, the arrows from the keyboard, the scroll of the mouse, the buttons in the popup. See also the help.
Marking this as not a bug.

Alright, sorry. I was sure to remember you could use the enter key to jump from one occurrence to the next as long as the search box was open.

Yeah, as Fabian said, you could keep pressing enter if the window was open. I understand that this is largely a matter of preference, but I'm personally finding difficult to adjust to. Given that Chrome and Firefox use both Enter and Ctrl+g to advance, I suspect others may be thrown off by this. Also, it's only a one line change: in gedit-view-frame.c/search_entry_activate, hide_search_widget becomes search_again. Seems to be working for me so far.

(In reply to comment #3)
> finding difficult to adjust to. Given that Chrome and Firefox use both Enter

... and Epiphany, too!

See the help for an explanation why use esc and enter for closing the popup. http://library.gnome.org/users/gedit/stable/gedit-search.html.en

(In reply to comment #5)
> See the help for an explanation why use esc and enter for closing the popup.
> http://library.gnome.org/users/gedit/stable/gedit-search.html.en

Still not convinced, though. This remains inconsistent with the behaviour of other programs, even other components of GNOME.

There are other bug reports on 
https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/873940
https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/887845

You can consider it as a bug or not but the behaviour is not consistent with other softwares and seems to behave in an unexpected way which confuses quites some users, it might be worth rethinking the logic...

dunno, this has been like this for several years. And once you get used to it, it is the right way to do it.

(In reply to comment #8)
> dunno, this has been like this for several years. And once you get used to it,
> it is the right way to do it.

I might be wrong, but I believe I remember that the behaviour was different in 2.28.x. This might be some releases ago, but I cannot track each and every GNOME release and was thus taken by surprise by this "new" behaviour.

However, the fact that it is like this for quite some time does not hide the fact that it is inconsistent with other applications. I consider it cumbersome to have to remember e.g. an Epiphany-way of searching for things and a Gedit-way.

Well, in gedit 2.28 control+f was launching the dialog while control+k was launching the interative search, (the default right now). If you want the previous behavior you can get it with control+h (the replace dialog) which is the same as the previous search dialog but with the replace options too.

The point that gedit is different from epiphany is that gedit is a text editor while epiphany is a browser. So gedit needs more actions for searching than what it can need epiphany. Please read the help document to learn all the capabilities of the interactive search popup.

(In reply to comment #10)
> Well, in gedit 2.28 control+f was launching the dialog while control+k was
> launching the interative search, (the default right now). If you want the
> previous behavior you can get it with control+h (the replace dialog) which is
> the same as the previous search dialog but with the replace options too.

I think the challenge here stems from user expectations and from users switching between multiple applications. Without an ability to customize keyboard keyboard bindings, gedit may be inconsistent with other applications the user frequently uses. These inconsistencies cause trouble and frustration for me (and I expect other users). 

Therefore, I suggest that this thread is a feature request to either:
(1) allow the user to select the action of the control F keyboard binding to make it the traditional dialog or the quick search
or
(2) to allow the user to determine the result of pressing enter in the quick search dialog.

As it stands, it is not valid to say that this behavior has existed for some time. It has not. In prior versions, a user would press Ctrl+F, enter a string, and press enter multiple times to repeatedly find that string. The same actions now produce a different behavior. The user should have a choice between these two behaviors via setting a preference pertaining to (1) or (2) above.

Just as a quick comment: you can change the shortcuts and put the replace dialog with the control+f shortcut. See:
https://github.com/nacho/gedit-accel-editor

or you can use the standard gtk+ way to change the shortcut.

Thanks, Ignacio, that's a big help and addresses my concerns. I forgot that gedit's shortcuts could be changed in the standard gtk+ way. I've never had an issue with the defaults in previous versions.  The plugin is very nice as well, as I learned a few new shortcuts via its edit screen. (I suppose I could have looked at the documentation to learn these shortcuts, but I have to say I don't often look at documentation and having the list of shortcuts within the app, editable nonetheless, is awesome).

Thanks!
Scott

(In reply to comment #12)
> or you can use the standard gtk+ way to change the shortcut.

And what is this "standard gtk+ way"?

(In reply to comment #14)
> And what is this "standard gtk+ way"?

Basically, find the command you wish to change the shortcut for in the menu bars (File, Edit, Search,etc.). With the mouse hovering over the menu item you wish to change, press a new keyboard shortcut. For this to work, you must have enabled the "can-change-accels" key in org.gnome.desktop.interface with dconf-editor.

Instructions and an example are at:
https://wiki.archlinux.org/index.php/GNOME#Changing_hotkeys

This is still terrible usability.  Way to go backwards in time.

Oh and also you can't change find next to enter, because enter still closes the find box.

Scott please see the previous comments in the bug if you don't like the current behavior.

*** Bug 663260 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> dunno, this has been like this for several years. And once you get used to it,
> it is the right way to do it.

I'd argue that the right way to do it is to do it in the way that's consistent with almost every other application on the planet, including Gedit 2 and major OS components like Firefox, Libreoffice, Chrome, etc., all of which use Enter to move to the next result.

(In reply to comment #10)
> The point that gedit is different from epiphany is that gedit is a text editor
> while epiphany is a browser.

So are Libreoffice Writer, Sublime Text, Geany, Komodo Edit etc., etc., and they all use 'enter' to move to the next result in their find dialogs.  In fact all of those examples are more hard-core text editors than Gedit is... Komodo is a fully-fledged IDE!

If the developer is the only one defending the choice, perhaps it's not the best choice?  *Please* consider going back to having the 'enter' key move to the next result so I don't have to be constantly hitting ctrl+z to undo the newlines I keep putting into my documents, and so I don't have to remember that Gedit is that one 'special' app that has bizzare shortcuts :(

Ok, let's reopen this and get suggestions for our use cases. First of all before trying to say just use enter for the next suggestion consider the next use cases for a text editor and not a viewer like the case of chrome of firefox.

* We need a way to go back and forward in the result, for this right now we use the arrows of the keyboard. You are meaning to use enter for going to the next, what would you use to go back and that it is handy?

* We need a way to get to the active occurrence, for this we use enter right now. What would you use instead?

* We need a way to cancel the search and go back to the place where we started the search. For this we use escape right now.

Do not recall if there was some other use case but that would be the main ones.

All the apps I've familiar with have the following setup for inline search:

Next result: enter
Previous result: shift + enter
Close search on active occurrence: esc

I'm not familiar with an app that has a "close inline search and return to top" but if you want to support that use case you could use shift + esc.

@alexander

Just a clarification that the last use case is not "return to the top" it is "return to where you were before you started the search." This is a useful feature: I might start a find look through a few matches and then decide I don't need to edit any of the matches and want to return to where I was in the document before I started the search. This may be line 1 or it may be line 901.

I'm fine with the proposed shortcuts or could also try:
Next result: enter or down arrow (this also makes it consistent with the find and replace dialog)
previous result: up arrow
Close search on active occurrence ctrl/shift+enter
close search and return to pre-find position: esc

I suggest this only because esc has the natural connection to cancelling something to me. And if a find is cancelled it makes sense to go back to where I was before I started. That said, I suspect that selecting the active occurrence will be used more than closing and returning to the pre-find position; so perhaps it makes sense for that to be a one-key command.

Part of the challenge overall is that a new user has no intuitive sense for how these keys are configured. It requires reading the manual to discover the commands. It would be great to display a tooltip/hint with information on the keyboard commands when the user hovers the mouse over the text field or over the previous/next occurrence buttons.

(In reply to comment #23)
> Part of the challenge overall is that a new user has no intuitive sense for how
> these keys are configured.

The ones I suggested are the shortcuts already commonly used in many major OS components, so the idea is that once a user knows how to go to the next/previous result or close the dialog in one app, they won't need to re-learn it for another.  

I don't know if it's possible in GTK but you could simply make 'enter' an additional shortcut and keep ctrl+g.  Firefox does this (at least, there may be more apps).

I was just making an update as you replied, Alexander. I think that's a good suggestion. After I tested a bit more with other programs
(Firefox, Chrome, LibreOffice -- I know these aren't text editors), I think
the suggestion to use shift+enter is good for consistency with these
other highly-used applications.

Ctrl+g and ctrl+shift+g are currently mapped in addition to up and down arrow in gedit. I think we need to keep these commands for those who are already used to them if it is not possible to otherwise allow the user to customize the key bindings.

Thus, I would propose.

Next result: enter or down arrow or the user mapped shortcut for Find Next (defaults to ctrl+g)
previous result: up arrow or shift enter or user mapped shortcut for Find Previous (defaults to ctrl+shift+g)
Close search on active occurrence esc
close search and return to pre-find position: shift+esc

I still think tooltips/hints would be helpful.

First off I want to thank you for hearing our suggestions and at least considering them.  I'm sure we can think of a solution that keeps all the functionality that we want in tact.

I would split the last requirement you listed into two different requirements.

* We need a way to cancel (close) the search.
* We need a way to go back to the place where we started the search.

It's the fourth requirement about going back to where we started that I think is the crux of our problem.  The previous search mode implementation went something like this.

1.  Use keyboard shortcut to bring up the search bar.  I think the previous one was a full dialog box, but the new mini-search box seems better.  The position in the text document remained where it was.
2.  Type our search.  In the previous implementation it didn't highlight entries until you hit enter.  The new highlighting as you go is also an improvement.
3.  Hit enter (or click find) to search.  This moved the cursor's position in the document to the next result from the previous cursor position.
4.  Hit enter again to go to the next result, or escape to close the dialog.  The cursor remains at the result you were just on.

In that old scheme, the idea was that you were searching for something, and when you've accepted that you found it, the cursor remains where you went.  The only thing it didn't do was have a way to bring you back to where your cusor was before you started the whole search process.  I think the idea to add this feature required you to change the entire method you were using to do search.  If you want to bring the user back, you need to either store two cursor positions or to never change the cursor to begin with as you search.  Obviously if you store two cursor positions it's hard to convey to the user where the previous one was, and they would be confused when brought back to the previous cursor position, so you went with never changing the cursor position.

Now to add this new functionality you have to add a new shortcut key, or use an existing one.  Escape has to be used to close the search bar, both in the old dialog box method and in the new mini-search field method.  This is because escape is the universal "close dialog or other small window" key.  Enter however is more ambiguous so you changed the enter key, and added control+g.

I think there are two reasons why enter should be the "find next but don't close the search" key.
1.  It's the standard in searching within documents, not just for text viewing programs but also for text editing programs.  Eclipse uses enter/shift enter for find next/previous.  Notepad in windows uses it (though they don't use shift+enter for previous).  You've already seen all the arguments about how all the browser and text viewers use it as well.  I can understand ignoring the reason of "most popular" if you have a good reason to though.  After all what if you came up with a more intuitive way?
2.  When you're typing, you are on your home row.  It's one of the very few times in using keyboard shortcuts when you're limited by this constraint.  When I'm alt+tabbing or navigating menus or closing tabs with keyboard shortcuts, I'm free to use any combination of keys that take my hand off of the home row, because I'm not exptected to be typing.  However the guess/check method that is so often used to figure out where we want to go in a text document requires us to type, search, type, search.  As such something like enter is extremely usable, and something like using the arrow keys is not.  Control+g (even if it was the standard and therefore our reflex for searching) is also risky because it's a missed control modifier away from accidentally typing and ruining our search.

Finally my argument for making the cursor move as you search.  Forgetting the enter key entirely for a moment, in the new gedit search let's say you're clicking the arrow buttons or using the arrow keys to navigate through the different search results that were found.  You're now on the third entry that's highlighted and you want to go to that point in the document.  At this point, users already think they are at that point in the document.  You've scrolled the current entry into view, it's highlighted, and the only thing letting them know that they aren't at this point in the document is the blinking cursor.  At this point the cursor might even be off screen, and if it is at the highlighted text, it will be very hard for them to notice, because they will notice the following things in order: highlighted text, screen position, blinking cursor.

The last thing I think that needs addressing is when to move the cursor.  If you're using search-as-you-type like the new gedit is, I can understand not moving the cursor for every letter they type.  You can still do this:
1.  When a user brings up the find box, the search entry text field becomes the focus.  Typing now goes into this field.
2.  When a user hits enter the first time, first (or current) selection is where the cursor is moved to.
3.  The user keeps hitting enter/shift+enter to scroll through the list of results, moving the cursor each time.
4.  The user either hits escape or clicks somewhere in the document and the find box goes away, leaving them where their search finished.  Perhaps clicking somewhere in the document doesn't close the find box, that's up to you really, but escape obviously should.

In the end it's a tradeoff between the scenarios of being able to return the cursor to where it was before any searching, and allowing the user to keep their "enter to search" functionality like it is everywhere else and keep theirhand on the home row for continued searching/editing.  I honestly don't know how often the first scenario of returning the cursor comes up, but it seems like it is definitely the least important of the two scenarios and if anything, it should be assigned the more obscure keyboard shortcut like <Control>+g.

Another thing to take into account and one of the important reasons we need to be able to come back to the position where we started to search is that right now the search is interactive while the previous one wasn't. And that's why this feature is so important.

I admit that using enter the first time to move the cursor and therefore "accept the search" (i.e. tell the search widget that you're done typing and ready to go to the place searched) isn't the best solution.  It seems like the only way to keep the interactive search.

Otherwise I'd make the argument that perhaps this is why text editors can't do the interactive searches while text viewers can.  I can't think of another text editor that does this.  They all use their find or find/replace dialog box instead.

A side note to anyone who wants to work around this for now, I just realized that you could rebind the find/replace dialog box to Ctrl+f for now.  Ctrl+h is the current shortcut for it.

See my comment in a duplicated bug here on how to change the shortcut if you need:
https://bugzilla.gnome.org/show_bug.cgi?id=663260#c3

(In reply to comment #28)
> Otherwise I'd make the argument that perhaps this is why text editors can't do
> the interactive searches while text viewers can.  I can't think of another text
> editor that does this.  They all use their find or find/replace dialog box
> instead.

Komodo Edit has an inline search triggered by ctrl + f that uses the proposed shortcuts I mentioned.  (Except it doesn't seem to have a "cancel search and return cursor" command).  It also has a find/replace dialog similar to most other applications.

Sigil (a major OSS ebook editor) also has inline find with the same shortcuts.  It's an exception for find/replace because in Sigil replace is also inline.

(In reply to comment #26)
> The
> only thing it didn't do was have a way to bring you back to where your cusor
> was before you started the whole search process.  I think the idea to add this
> feature required you to change the entire method you were using to do search. 

Great comments, Scott. Just to note that this is not a new feature per se. As noted previously this was all introduced simply with a change of default keybindings. Ctrl + f now brings up the Quick search (mini-)dialog. This was previously bound to ctrl+k in previous versions of gedit and worked exactly as it does in the current version. Likewise, ctrl+g has existed for many versions (at least as far back as 10.04, which I have on an old machine).

As noted in comment 12 above the keybindings can be customized to change quicksearch back to ctrl+k and put the find and replace dialog as ctrl+f. The find dialog has been dropped.

I think the cancel and return to pre-find location is necessary if we continue to search actively as the user types and possible even if we went back to the press Enter to find first occurrence that Scott mentions. There is a good use case for wanting to return to where you were before starting the search -- e.g. you realized after looking through several matches that what you were searching for isn't there, etc. and want to be back to where you started. I think keeping an unlikely to be confused key (e.g. shift+esc) for this is good.

*** Bug 699658 has been marked as a duplicate of this bug. ***

I agree with the original reporter and Scott; this is completely inconsistent with how almost every other piece of software behaves. I have caught myself expecting "Enter" to advance to the next result several times during my test-drive of gedit 3.10.4, and have become extremely frustrated.

Though Scott has mentioned some already, here are some more examples of popular software where pressing "Enter" advances to the next Find result when the Find dialog is in focus:
    Evince (3.10.3)
    Epiphany (3.10.3)
    Firefox
    Chrome 
    LibreOffice

It seems to me this inconsistency should be corrected. The defaults should be consistent with user expectations.

+1 for making the controls consistent with other applications.

I've been using Gedit for a few years now.  I really love it, but I will never get used to having to use the Gedit-style text search.

When I'm coding, I'm quickly flipping between a few of Firefox, Qt Creator, Spyder, LibreOffice, Okular and Gedit.  The first five are completely consistent, but I stumble every time I switch to Gedit and do a text search.

I can't tell you how many times I've done:

<CTRL+F> <ENTER> <ENTER> <ENTER> ....  "oh crap!" ... <CTRL+Z> <CTRL+Z>... "alright, Gedit mode"...  <CTRL+F> <CTRL+G> <CTRL+G> <CTRL+G>  etc.

Created attachment 297542 [details] [review]
search: go to the next occurrence when hitting enter

Sorry, after attaching the patch I noticed it doesn't account for all the features needed (search backwards and close search with the cursor over the result).

See Comment 21 and Comment 27. There are good reasons behind the chosen shortcuts. The solutions proposed in Comment 22 or Comment 23 don't seem better, because using shift+enter or shift+esc is more complicated and is less logical.

- Using the up and down arrows for navigating through the occurrences makes perfect sense to me.

- Using Enter to say "OK, the search was successful, I've found what I wanted to search" also makes sense. When you enter a login/password and press Enter, it's the same thing, you validate your login/password. For the search, you validate the search (i.e. the place where you're now).

- And using Escape for canceling an operation is also the right key.

So, let's close this bug.

It is very sad, that the voices of the users get ignored:

one user wrote:

> When I'm coding, I'm quickly flipping between a few of Firefox, Qt Creator, 
> Spyder, LibreOffice, Okular and Gedit.  The first five are completely 
> consistent, but I stumble every time I switch to Gedit and do a text search.

It is the same for me. Gedit is fine, but searching is a pain.

The good news: We (users) can choose and .... leave.

Goody bye

Please consider reopening this.