After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749117 - Change behavior of CTRL+F to match firefox, chrome, sublime text ...
Change behavior of CTRL+F to match firefox, chrome, sublime text ...
Status: RESOLVED FIXED
Product: gnome-builder
Classification: Other
Component: editor
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-08 14:23 UTC by Wolf Vollprecht
Modified: 2015-05-09 19:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for CTRL+F behavior (3.34 KB, patch)
2015-05-09 11:06 UTC, Wolf Vollprecht
committed Details | Review

Description Wolf Vollprecht 2015-05-08 14:23:56 UTC
I know this might be controversial, and GEdit is the same. 

But my (and I suppose most people's) muscle memory adapted to the CTRL+F behavior of many other tools.

I.e. 

Enter -> next search entry (Tab + Enter prev search results)
ESC -> remove focus and hide search box again

I think that combination is much better, as on many notebooks the enter key is prominent and big, while the arrow keys are quite small and also harder to reach.

I think it would be good to adapt that as default behavior as so many other editors have it (jetbrains, sublime text ... ) and have an option (maybe hidden in gsettings) to revert to the GEdit style of searching.
Comment 1 Wolf Vollprecht 2015-05-09 11:06:21 UTC
Created attachment 303118 [details] [review]
Patch for CTRL+F behavior

I have created a patch with my desired behavior of ctrl+f.

it also contains additional functionality for remembering the previous search as well as automatically adding the currently selected string if something is selected to the search entry.

PS. I don't know if I need to free the previous_search_string somewhere? Not a C/glib pro ...
Comment 2 Wolf Vollprecht 2015-05-09 11:07:36 UTC
Just realized that I wrote 'Tab+Enter' but actually meant 'Shift + Enter' of course.
Comment 3 Christian Hergert 2015-05-09 19:12:08 UTC
I've pushed this with some followup up commits which address the leaks, style, and ensuring we scroll back to the insert mark when refocusing the view.

I can't guarantee that behavior will stay like this forever (we need to do a bunch of iteration on search), but this is clearly better than what we had.

Thanks!
Comment 4 Wolf Vollprecht 2015-05-09 19:52:51 UTC
That's really cool!

I just realized another small issue: After searching and pressing enter + escape, the cursor is at the beginning of the search match. 

I think it would be best if the match is selected and the cursor at the end of the selection. 

Cheers,

Wolf