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