GNOME Bugzilla – Bug 745790
Search at word boundaries doesn't work with words that start with underscore
Last modified: 2016-06-11 17:00:09 UTC
The comportment expected with the * command is to find every other occurrences of the current word under the cursor. But when this word start with the underscore character, like private methods in the Python coding style convention, the search is not working.
This is somewhat related to bug 742976 although it is probably a different issue, but fixing the word boundary issue might fix the underscore one as a side effect?
Created attachment 319971 [details] GtkSourceView test search widget
It's a GtkSourceView or maybe Pango prob, you can test it in the GtkSourceView search widget ( gtksourceview/tests/test-search ) We do search with at_word_boundaries activated
More probably a bug in gtksourceiter.c.
Hum no, the SearchContext doesn't use gtksourceiter functions… So it's more probably a bug in Pango word breaking rules.
maybe gsv search behaviour should use gtksourceiter ? there's underscore things in
Yes the Pango word boundaries take into account only natural-language words, which doesn't include the underscore. The gtksourceiter functions are normally very similar to the GtkTextIter ones, so using gtksourciter in the SearchContext should not be too hard to do.
In gtksourceiter.h, there are two sections: the semi-public functions and the internal functions used only for the unit tests. For the SearchContext I think the best would be to use the "extra-natural word" boundaries, that is, a natural-language word as defined by Pango, plus the underscore. So those internal functions that deal with extra-natural words should be made semi-public.
Hi!i would like to work on this bug.. Any advice?
It's an open question. The answer might be long depending on your experience, and I don't know if you are comfortable with GLib/GTK+. If you have more specific questions, don't hesitate to ask. This might be useful: https://people.gnome.org/~swilmet/glib-gtk-dev-platform.pdf
Done: commit 958eadb4d69ddea793fffe71050453eba024caee commit 64e248ab54ed76c6be2f1805328b5b22f1c6141a