Improve word boundaries for text widgets

[Sébastien Wilmet <swilmet gnome org>]

Hi,

Several months ago I started working on improving the word boundaries,
I've written some patches, written some comments on bugzilla in various
bugs. Here is a summary, I hope it'll get more attention than in
bugzilla.

I would like to improve the word boundaries for the text widgets:
GtkTextView, GtkEntry and GtkLabel (anything else?). More precisely the
word boundaries used for word movements (Ctrl+arrow) and word selection
(double click). Currently the behavior is not consistent across the text
widgets in GTK+ (and other applications), and the current word
boundaries don't work well with spaces, punctuations,
variables_with_underscores, etc.

The word boundaries currently used are those returned by Pango for
natural-language words. Those word boundaries are suitable for a spell
checker, since the spell checking should be run only on natural-language
words. But for word movements and word selection this doesn't work well
directly.

By seeing how Vim handles word movements, I think it's a much better
behavior. Deriving the "Vim" word boundaries from the Pango word
boundaries is quite straightforward (I have a workable patch): it uses
only the is_word_start and is_word_end PangoLogAttr attributes,
g_unichar_isspace() and compare if a character is an underscore.

Another idea for GtkTextView is to add a vfunc to let GtkSourceView
define custom word boundaries for word movements and selection. But
all what GtkSourceView would do is to define the "Vim" word boundaries,
which are generic. The Vim word boundaries are good enough, we don't
need more flexibility. So I prefer to implement directly the Vim word
boundaries in GTK+, and have a consistent behavior with other widgets.

Longer-term, we can maybe think about moving the Vim word boundaries
algorithm in Pango, so other applications like Firefox can also have the
same behavior. But in the meantime we can have internal utilities
functions in GTK+ that would be used by all text widgets, so the code
would have the time to maturate before going to Pango.

Do you think it's a good plan?

Thanks,
Sébastien