• Mouse "words" vs. keyboard "words"

    From Eric Brunel@eric.brunel@pragmadev.invalid.com to comp.lang.tcl on Tue Jun 3 13:14:41 2025
    From Newsgroup: comp.lang.tcl

    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!
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Harald Oehlmann@wortkarg3@yahoo.com to comp.lang.tcl on Tue Jun 3 15:33:04 2025
    From Newsgroup: comp.lang.tcl

    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

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Eric Brunel@eric.brunel@pragmadev.invalid.com to comp.lang.tcl on Fri Jun 6 12:29:51 2025
    From Newsgroup: comp.lang.tcl

    On Tue, 3 Jun 2025 15:33:04 +0200, Harald Oehlmann wrote:

    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

    Thanks once more, Harald, will do!

    Cheers.
    --
    Eric
    --- Synchronet 3.21a-Linux NewsLink 1.2