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 765889 - Vim mode: * and # don't match entire word and take number prefix properly
Vim mode: * and # don't match entire word and take number prefix properly
Status: RESOLVED OBSOLETE
Product: gnome-builder
Classification: Other
Component: editor
3.21.x
Other Linux
: Normal minor
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
: 745791 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-05-02 03:01 UTC by Fangwen Yu
Modified: 2018-01-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix * and # in vim mode (883 bytes, patch)
2016-05-02 03:01 UTC, Fangwen Yu
none Details | Review
fix * and # in vim mode (2.20 KB, patch)
2016-05-02 06:01 UTC, Fangwen Yu
none Details | Review
ide-source-view-movements: treat underscore as word boundary (3.98 KB, patch)
2016-05-04 05:55 UTC, Fangwen Yu
none Details | Review

Description Fangwen Yu 2016-05-02 03:01:53 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.
Comment 1 Fangwen Yu 2016-05-02 06:01:58 UTC
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.
Comment 2 Christian Hergert 2016-05-03 09:37:03 UTC
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.
Comment 3 Christian Hergert 2016-05-03 09:38:46 UTC
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?
Comment 4 Fangwen Yu 2016-05-03 14:26:43 UTC
(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.
Comment 5 Fangwen Yu 2016-05-04 05:55:05 UTC
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.
Comment 6 Christian Hergert 2016-05-04 06:03:28 UTC
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?
Comment 7 Sébastien Wilmet 2016-05-05 18:47:57 UTC
There is also the related bug #745790. But if more flexibility is needed, then an enum type would be nice, yes.
Comment 8 Christian Hergert 2016-05-06 05:49:34 UTC
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.
Comment 9 Christian Hergert 2016-05-06 05:52:31 UTC
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?
Comment 10 Sébastien Wilmet 2016-05-06 08:34:28 UTC
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.
Comment 11 Alexandre Franke 2017-01-19 11:14:42 UTC
*** Bug 745791 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2018-01-11 10:03:48 UTC
-- 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.