Re: Improve word boundaries for text widgets
On Fri, Oct 03, 2014 at 10:25:36PM -0400, Matthias Clasen wrote: I think I want the default in GtkTextView/Pango to stay basically Unicode. So the vfunc may be needed sooner if you want to have vim-like behaviour in GtkSourceView. What do you mean by basically Unicode? The problems in GTK+: - the behavior is not consistent between GtkEntry and GtkTextView (and possibly GtkLabel too for word selection). - the current behaviors don't work well, since it uses only natural-language word boundaries. So I want to fix both points. When playing with GtkEntry and GtkTextView, we can clearly see some differences, and we can also see that the behavior is sometimes strange. For example with this line: g_assert_cmpint (pos - str, ==, 5); In GtkEntry, double click on the 's' of str. Then double click on the 't' of str. In the first case, - str is selected; in the second case str is selected. With GtkTextView only str is selected for both cases. Double click on ==, it will select , ==, . In GtkTextView, place the cursor just before g_assert (with the two spaces before). Ctrl+left doesn't go to the start of the line. GtkEntry does. And of course g_assert_cmpint is not one word. A more realistic example for GtkEntry: foobar -- blah Place the cursor at the start. Press Ctrl+right several times. -- is skipped. Do I continue? -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve word boundaries for text widgets
On Sat, Oct 4, 2014 at 8:24 AM, Sébastien Wilmet swil...@gnome.org wrote: On Fri, Oct 03, 2014 at 10:25:36PM -0400, Matthias Clasen wrote: I think I want the default in GtkTextView/Pango to stay basically Unicode. So the vfunc may be needed sooner if you want to have vim-like behaviour in GtkSourceView. What do you mean by basically Unicode? I mean that it is the right default behavior to follow Unicode TR 29. The problems in GTK+: - the behavior is not consistent between GtkEntry and GtkTextView (and possibly GtkLabel too for word selection). - the current behaviors don't work well, since it uses only natural-language word boundaries. So I want to fix both points. Fixing internal inconsistencies is a good idea, of course. Patches for that would be most welcome. For tayloring the text segmentation behavior for special situations, such as code instead of natural language, a vfunc is the right approach. Does that make clear what I would like to see ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve word boundaries for text widgets
On Sat, Oct 04, 2014 at 12:30:43PM -0400, Matthias Clasen wrote: I mean that it is the right default behavior to follow Unicode TR 29. If we want to follow Unicode TR 29, then we should use the is_word_boundary PangoLogAttr attribute, see: https://bugzilla.gnome.org/show_bug.cgi?id=530405 As I explained there, I've done some experiments with is_word_boundary, and it is not convenient to use directly. Using is_word_boundary gives probably better results for the whole-word search. But for word selection and word movements, it's not convenient, another algorithm on top of is_word_boundary would be needed to achieve good results (at least as good as the current behaviors in GTK+ that use is_word_start and is_word_end). With is_word_start and is_word_end, we have two word boundary types. It is needed for word movements: ctrl+right goes to the next word _end_, ctrl+left goes to the previous word _start_. With is_word_boundary, we don't know if a word boundary is at the start or end of a word. For word selection (double click), one word boundary type is needed. It is easy to go from two word boundary types to one, utilities functions can be written. Doing the contrary is more difficult. So, since is_word_boundary doesn't give good results for the word selection, using is_word_start and is_word_end is easier (through the utilities functions). But, is_word_start and is_word_end are only for natural-language words. It doesn't take into account the punctuation, that can also occur for normal text. If we want to follow Unicode TR 29, we can see here: http://www.unicode.org/reports/tr29/#Word_Boundaries that there are word boundaries for punctuation too. It is explained that word boundaries can be tailored for some features. For example the whole-word search can have different word boundaries than word selection. And I think the Vim word boundaries as used by the 'e' and 'b' commands are suitable both for normal text and code. It would be a consistent behavior across all GTK+ text widgets, including GtkSourceView for the code. Fixing internal inconsistencies is a good idea, of course. Patches for that would be most welcome. For tayloring the text segmentation behavior for special situations, such as code instead of natural language, a vfunc is the right approach. Does that make clear what I would like to see ? But the Vim word boundaries improve the behavior also for normal text, not just code. Vim can be used to write mails and documents. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve word boundaries for text widgets
On Sat, Oct 4, 2014 at 1:48 PM, Sébastien Wilmet swil...@gnome.org wrote: On Sat, Oct 04, 2014 at 12:30:43PM -0400, Matthias Clasen wrote: For tayloring the text segmentation behavior for special situations, such as code instead of natural language, a vfunc is the right approach. Does that make clear what I would like to see ? But the Vim word boundaries improve the behavior also for normal text, not just code. Vim can be used to write mails and documents. this is none of my business, but it seems fairly clear to me what matthias wants: step 1: create a vfunc for this step 2: implement a version of the vfunc that implements whatever behaviour you want what i think matthias doesn't want: step 1: implement the behaviour you want step 2: think about adding a vfunc i'm sure he'll correct me if i got this wrong. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve word boundaries for text widgets
On Sat, Oct 4, 2014 at 1:52 PM, Paul Davis p...@linuxaudiosystems.com wrote: But the Vim word boundaries improve the behavior also for normal text, not just code. Vim can be used to write mails and documents. this is none of my business, but it seems fairly clear to me what matthias wants: step 1: create a vfunc for this step 2: implement a version of the vfunc that implements whatever behaviour you want what i think matthias doesn't want: step 1: implement the behaviour you want step 2: think about adding a vfunc i'm sure he'll correct me if i got this wrong. My main motiviation is that 'we follow TR29' is much better in terms of documenting it, testing it and diagnosing bugs in than 'do what vim does'. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve word boundaries for text widgets
On Sat, Oct 04, 2014 at 02:10:02PM -0400, Matthias Clasen wrote: My main motiviation is that 'we follow TR29' is much better in terms of documenting it, testing it and diagnosing bugs in than 'do what vim does'. That would work if TR29 specifies clearly the different word boundaries to use for the different features. But it is not the case. Instead, TR29 specifies generic word boundaries that should be tailored for the different features, and the tailoring is left as an exercise for the reader. For the documentation, no need to mention Vim, the Vim word boundaries can be summarized easily. A word is either: - a natural-language word that can include the underscore character; - a contiguous group of non-blank characters. But anyway, this is an implementation detail. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
