Re: Improve word boundaries for text widgets
On Sat, Oct 04, 2014 at 08:54:03PM +0200, Sébastien Wilmet wrote: 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 what it's worth, LibreOffice Writer also takes into account the punctuation for word movements and word selection. ___ 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 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
Re: Improve word boundaries for text widgets
On Sat, Sep 27, 2014 at 7:39 AM, Sébastien Wilmet swil...@gnome.org wrote: On Sat, Sep 27, 2014 at 12:47:31AM -0400, Matthias Clasen wrote: I agree that we probably need a vfunc - there's different use cases that need different variants: natural language, code, xml, etc. For best results, we may even want a way to use different word breaking rules in different regions of the buffer. As an example, you might have comments embedded in code. So having better defaults in GTK+ would be a first step, I think it's more important. The vfunc can be added later. 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. ___ 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 09/27/2014 04:52 AM, Sébastien Wilmet wrote: I'm doing exactly this in Builder today for VIM style `w` and `b`. Ctrl+right is the same as 'e' in Vim: go to the next word end. Ctrl+left is the same as 'b' in Vim: go to the previous word start. Is there a good reason to choose 'w' instead of 'e'? I think 'e' and 'b' are better for word selection with Ctrl+Shift+arrow. I just want to have a small VIM compatibility layer for some of us that can't change our mental model to a non-modal editor. I'm not totally sure I'll go through with this fully, but it's worth spending a day or two prototyping on top of GtkTextView/GtkSourceView. -- Christian ___ 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, Sep 27, 2014 at 12:47:31AM -0400, Matthias Clasen wrote: I agree that we probably need a vfunc - there's different use cases that need different variants: natural language, code, xml, etc. For best results, we may even want a way to use different word breaking rules in different regions of the buffer. As an example, you might have comments embedded in code. So having better defaults in GTK+ would be a first step, I think it's more important. The vfunc can be added later. ___ 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 Fri, Sep 26, 2014 at 04:37:52PM -0700, Christian Hergert wrote: I'm doing exactly this in Builder today for VIM style `w` and `b`. Ctrl+right is the same as 'e' in Vim: go to the next word end. Ctrl+left is the same as 'b' in Vim: go to the previous word start. Is there a good reason to choose 'w' instead of 'e'? I think 'e' and 'b' are better for word selection with Ctrl+Shift+arrow. Additionally, I'd like double-click and triple-click to be different things. Imagine triple-click selecting the whole scope in some C code for example. Currently triple-click selects the line, it's not that bad. But being able to change the behavior can be useful, I'll keep that in mind for the vfunc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Improve word boundaries for text widgets
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 ___ 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 09/26/2014 06:13 AM, Sébastien Wilmet wrote: 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. Awesome! 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. I'm doing exactly this in Builder today for VIM style `w` and `b`. 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. I would really like this to be a vfunc so that it could be handled by per-language overrides in GtkSourceView/GtkSourceLanguage. Additionally, I'd like double-click and triple-click to be different things. Imagine triple-click selecting the whole scope in some C code for example. Do you think it's a good plan? I can't speak for everyone, but clearly useful for me on Builder. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
