Re: Mouse "words" vs. keyboard "words"

Am 03.06.2025 um 15:14 schrieb Eric Brunel:

Hello all,
 
I noticed something with tk 9.0.1 that I find a little bit confusing.
According to the man pages, in the text widgets, here is the behavior
of some of the bindings related to words:
 
- In the "Bindings" section, list item 2, it is specified that "Double-
clicking with mouse button 1 selects the word under the mouse";
- In the same section, list item 9, it is specified that "Control-Left
and Control-Right move the insertion cursor by words".
 
So far so good. Now let's try: in a text widget, I type the text
"foo.bar". If I double-click on "foo" or "bar", it selects the word
"foo",
or the word "bar", respectively. Now if I put my insertion point just
after "bar" and press Control+Left, I would expect the insertion point
to move at the beginning of "bar". But that's not what it does: it
moves before "foo", as if the "." was part of the word, when it wasn't
with the double-click. And same the other way: if my insertion point is
before "foo" and I press Control+Right, the insertion point moves after
"bar".
 
I get caught every time I try to move my cursor by words with the
keyboard, and it's kind of annoying. Also, I tested with tk 8.6 and it
wasn't what it was doing, at least on Linux: Control+Left and
Control+Right were identifying words the same way as the double-click
does.
 
Is the tk 9.0 behavior intentional? If it is, why are words when using
the mouse different from the words when using the keyboard? Is there a
rationale behind that?
 
Cheers!

 
I think, it is a bug.
In Tk 8.6, there was a simple algorithm to look for separation
characters.
In Tk 9.0, word boundary detection is now done by the unicode ICU
library. Special reason is, that there are languages, where the word
boundaries are not trivial at all (Thai for example).
 
I suppose, the "click on" feature still uses the old algorithm, and the
"next/prev" key uses the new one.
 
Please file a bug report.
 
Thanks,
Harald