GNOME Bugzilla – Bug 765889
Vim mode: * and # don't match entire word and take number prefix properly
Last modified: 2018-01-11 10:03:48 UTC
Created attachment 327122 [details] [review] fix * and # in vim mode The * and # search movements in vim mode are somewhat broken. How to reproduce: 1) Open a file with 4 words: hello hello ahello ahello 2) Put the cursor on the 2nd "hello", hit * so the cursor moves to ahello. 3) Hit another * and it is now searching for "ahello" (rather than "hello"). The actual cause of this problem is that the * and # search movements in vim mode do not match the entire word, and they should. The keybindings for * and # correctly specify the word_boundries setting in vim.css, but it is not respected by ide_source_view_real_move_search(). The attached patch fixes this problem.
Created attachment 327127 [details] [review] fix * and # in vim mode I've found two other problems regarding * and # search in vim mode. 1) If the word under cursor is at the beginning of the buffer (character offset 0), the search will skip the next one (and move to the 3rd occurrence). 2) * and # don't take number prefix properly. The updated patch fixes the problems of * and # search in vim mode, so that * and # can 1) match entire word. 2) work correctly regardless of where the search begins. 3) take number prefix properly.
This still doesn't seem to be quite right for me with #. move to word inside include like "build" in #include "foo-build-file.h" hit # i land on foo_build_file_init at the end of the file.
Either way though, this is an improvement, so I'm going to push the patch. But we can probably leave the bug open for further improvements?
(In reply to Christian Hergert from comment #2) > This still doesn't seem to be quite right for me with #. > > move to word inside include like "build" in #include "foo-build-file.h" > hit # > > i land on foo_build_file_init at the end of the file. * also has this problem. The actual cause is that the various ide movements treat foo-build-file as three words, but treat foo_build_file as one word. I will modify ide-source-view-movements.c to see if I can resolve this bug.
Created attachment 327263 [details] [review] ide-source-view-movements: treat underscore as word boundary An underscore is treated as word boundary in gtksourceview, while in Builder it is not, thus causing the previous problem we had. Note that Vim also treats underscore as part of a word. The latest patch tries to match the behavior of gtksourceview. This also changes the behavior of "b" and "<ctrl>w" in Vim mode. It doesn't affect double-click word selection. Not sure if it's the right change to make since by applying the patch, we are not matching Vim's behavior in Vim mode. However, if we are going to match Vim's behavior, when we do * search for "foo" (should match entire word), it must not match "foo_bar", and it would require modifying gtksourceview.
I definitely don't want to break Vim word movements. Movements are one thing I've found essential to getting me out of Vim, and I assume it will make it incredibly difficult for us to win over current Vim users. Maybe Sébastien or Paolo have a suggestion on how we could teach GtkSourceSearchSettings about different word boundaries? Maybe we could have a GtkSourceSearchWordBoundary enum type?
There is also the related bug #745790. But if more flexibility is needed, then an enum type would be nice, yes.
We have a couple of other word classifications in Builder due to supporting Vim movements, so I can at least see an argument for an enum. And because it's Vim, they are all terribly named. words, WORDS, (paragraphs and sentences) A word consists of a sequence of letters, digits and underscores, or a sequence of other non-blank characters, separated with white space (spaces, tabs, <EOL>). This can be changed with the 'iskeyword' option. An empty line is also considered to be a word. A WORD consists of a sequence of non-blank characters, separated with white space. An empty line is also considered to be a WORD. I don't think paragraphs vs sentences are interesting here though.
If we were to have the equivalent of words and WORDS, that would mean 3 distinct modes for GtkSourceView to handle. default breaks (as defined by gtktextiter) word breaks (similar to your underscore text iter work) WORD breaks (extension of underscore to be any non-whitespace) I'm sure we can come up with more, but enums would be extensible and we already know we could reasonably have 3. Anyway, maybe this is worth implementing this cycle? Sébastien, I know your time for GtkSourceView is limited, but if Fangwen or I implement this, would you have time to review?
If you look at gtksourceiter.h, there is also: - full word (the same as WORD I think) - extra-natural word: a natural word as defined by Pango/GtkTextIter, plus the underscore, but the set of extra chars could be configurable. Note that with regex search the word boundaries are different, it relies on GRegex and thus the libpcre. I have the time to review patches.
*** Bug 745791 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-builder/issues/115.