GNOME Bugzilla – Bug 111503
Customization of text selection bounds on double click
Last modified: 2014-12-25 21:34:31 UTC
I have just found a couple of problems with text selection on double click. Problem 1 ========= In an empty text view write: ciao this_is_a_test ciao with the left button of the mouse double click near the 'h'. Only "this" is selected. IMO, "this_is_a_test" should be selected. If you click just before a '_', nothing is selected. IMO, "this_is_a_test" should be selected. If you click just after the fist '_', "is" is selected, IMO, "this_is_a_test" should be selected. And so on. Problem 2 ========= In an empty text view write: ciao test00test ciao If you double click near the first 'e', "test" is selected. IMO, "test00test" should be selected. If you click just before the first '0', nothing is selected. IMO, "test00test" should be selected. If you click just before the second '0', only the second '0' is selected, IMO, "test00test" should be selected. If you click just after the second '0', nothing is selected. IMO, "test00test" should be selected. If you click just before (or after) the second 'e', "est" is selected, IMO, "test00test" should be selected. I'm not sure if these are GtkTextView or Pango problems. Probably problem 1 is a text view problem, while problem 2 is a pango one, but I really don't know. Is this a duplicate of bug #97545 ?
text view just uses the pango word break stuff for word breaking, so if you're suggesting the word breaking work differently, it's either a dup of bug 97545 or it's a bug against the Unicode technical report. If you wanted you could turn this bug into "provide hooks to change word selection behavior for special-purposes text view uses such as code editors" since the pango stuff is clearly designed for natural language, not code. However, it isn't totally obvious to me what the API for hooks like that would be like.
Is there a suggestion here that double clicking on words should behave different than cursor movement through words? Having cursor movement stop on _ is one of the reasons that the GNU coding standards suggest using _ within identifiers; it defiinitely can be seen as a feature. I suspect that there isn't a one-size-fits-all solution for double click selection; some people want to select URL's, some people want to select C identieres, etc. So, perhaps it would be best to simply have a hook to allow it to be customized - perhaps a boolean-handled signal like: gboolean ::select_surrounding_word (buffer, iter);
*** Bug 93711 has been marked as a duplicate of this bug. ***
Bug 93711 discusses desirability of customization for both double-click boundaries and word navigation boundaries.
*** Bug 312112 has been marked as a duplicate of this bug. ***
I have marked bug #312112 as a duplicate of this bug event if it focuses more on the differences among various gnome apps. It seems that most of the gnome apps (that do not use GtkTextView) do not use the algorithm proposed in the "Unicode Technical Report #29" for word breaking. Is this an important problem from the constency point of view? Should we file bugs against all these apps? Should we fix GtkTextView? Which is the behavior most users are expecting? I don't think adding a hook to allow customization is the real solution here, since it will create inconsistency also among the apps using GtkTextView. Adding usability guys to CC list.
*** Bug 314371 has been marked as a duplicate of this bug. ***
I'm sorta looking at this bug for MonoDevelop the problem isn't just _'s, it's also numbers. take for example, we have a variable named "button2" double-clicking to select the variable name will select only "button", not including the "2" using shift-left or shift-right also treats the "button" and "2" as different words. (which as has been mentioned earlier in this report are due to the pango breaking logic) (I bring this up as another scenario for the usability guys to note)
One simple solution is to have a simple funtion in gtktextview to let others set 'word characters'. GtkTreeView can then identify a word easily either for double click selection or get_current_word(). I am not sure if can/should work for unicode words.
TR #29 says: "There is no requirement that Unicode-conformant implementations implement these default boundaries. As with the other default specifications, implementations are also free to override (tailor) the results to meet the requirements of different environments or particular languages." Meanwhile, I don't think anyone has yet provided a rationale for allowing customization of word break characters. For problem 1, I can think of zero examples where _ should not be treated as a word separator, and one example where it should (identifiers in programming). For problem 2, I can think of plenty of examples where adjacent alphabetic and numeric strings should be treated as the same word (tax forms 1040EZ and IR330, pencil hardnesses 2H and 5B, variables x1 and x2, Bananas in Pyjamas B1 and B2), and zero examples where they should be treated as separate words. Even if there were small app-specific benefits from customization, I think that would not be worth the overall inconsistency between applications. Inconsistency in the behavior of basic actions (such as mouse clicks and key presses) is the worst kind. <http://www.asktog.com/basics/firstPrinciples.html#consistency> The same applies (to a lesser extent) to consistency between operating systems: neither Windows nor Mac OS behave in the manner requested in Problem 1, but both behave in the manner requested in Problem 2.
As the reporter of this bug I'd love to see examples of where _ is used in day to day use. This is specifically in reference to the comment "I can think of zero examples where _ should not be treated as a word separator". While I'm happy to keep and open mind about this, I couldn't think of a usage of _ in you average day of writing, apart from a bounding ruler, or a spot for someone to add comments on a form, for eg. Name: ______________________________________________________________________ If _ is to be thought of a 'word seperator' home much of the line above should be selected if you double click somewhere in the line. ;-] So, I guess I'm asking for examples where _ should be used as a word seperator.
An example in front of me right now is code that uses a function "find_tag_by_id". Fairly often I change this to "find_tag_by_class", or vice versa, and being able to double-click on the last word to change it is convenient. My main point is, I would much rather have a single behavior that worked everywhere in the operating system, than a behavior customized by individual applications. Make it configurable if you really want, but make that configuration OS-wide, so that you're never surprised about different behavior in a newly-installed (GTK) application.
*** Bug 388099 has been marked as a duplicate of this bug. ***
*** Bug 691688 has been marked as a duplicate of this bug. ***
Created attachment 292673 [details] [review] textview: add extend-selection signal To be able to customize the double-click and triple-click behaviors, to provide other selection boundaries. Note that the GtkTextExtendSelection enum contains DOUBLE_CLICK and TRIPLE_CLICK, not WORDS and LINES, so totally different boundaries can be provided, it is not restricted to words for double-click and lines for triple-click. For example a triple-click on some C code could select the current scope.
So here is a first version of a patch. I'm not sure if the "extend-selection" signal name is good, neither for the GtkTextExtendSelection enum. I think we can assume that the double-click and triple-click extend the selection. If a completely different behavior is wanted (e.g. show the context menu on triple-click, why not...), then the application has to capture the event before GtkTextView. Note that a different approach to solve the problem for the double-click (not triple-click) is available in bug #562767.
I'd rather stay with the words/lines terminology. If you decide to select syllables instead of words in your application, thats your business. But using double-/triple-click for something that is also used for keynav and touch is actively misleading.
The signal would not be used for keynav, since the ::move-cursor and ::delete-from-cursor signals can already be easily overridden. But as far as I understand the code, the new signal is also used for touch, so indeed the "click" terminology is not great.
Created attachment 292751 [details] [review] textview: add extend-selection signal To be able to customize the double-click and triple-click behaviors, to provide custom selection boundaries.
Review of attachment 292751 [details] [review]: Looks good. Woud be nice to have an example of this in action, but that can come later.
The commit is pushed to the master branch: https://git.gnome.org/browse/gtk+/commit/?id=020258f85a4add53e9f04fce39f1ba3e89f9abae Thanks for the reviews! The signal will be used in GtkSourceView ASAP.
*** Bug 562767 has been marked as a duplicate of this bug. ***
The signal is now used in GtkSourceView: https://git.gnome.org/browse/gtksourceview/commit/?id=6023c13c95d7240bac29705ed9768c3306ef2450