Hello all ... learning some Tk here ...

After playing around with Tk's lovely text megawidget, I've been
annoyed by the "line jumping" behavior when you click on the empty
area to the right of the text. Am I the only one that expects the
cursor to stay on the last char of the line, instead of jumping to the
first char of the next one? All editors I've used stay on the line
when you click on the empty area on the right.

For instance, try this in wish:

pack [text .t] -expand yes -fill both
.t insert end "hello\nthis is another line"

Make sure there is plenty of empty area to the right of the first
line. Now put the mouse pointer on the first line a little bit to the
right of the "hello", and start clicking and moving the cursor to the
right (click, move, click, etc). After the mouse pointer crosses the
middle of the empty area, on click the insertion cursor jumps to the
first char of the next line (before "this") instead of staying at the
end of the line (i.e. to the right of the "o"). I didn't expect this
behavior.

I don't know whether this is the intended behavior, but anyway I found
a little temporary fix for it, as follows.

In Tk 8.6.12, look for the `tk::TextClosestGap` procedure in
`text.tcl`, here it is (with minor reformatting):

proc ::tk::TextClosestGap {w x y} {
set pos [$w index @$x,$y]
set bbox [$w bbox $pos]
if {$bbox eq ""} {
return $pos
}
if {($x - [lindex $bbox 0]) < ([lindex $bbox 2]/2)} {
return $pos
}
$w index "$pos + 1 char"
}

That routine is directly invoked by tk::TextButton1 (on click) to set
the insertion cursor. It seems the second `if` is trying to determine
whether the click position ($x,$y) is horizontally on the left half of
the bounding box for the char at position $pos (which is under the
mouse pointer ($x,$y) according to `index`), and if so, $pos remains
where it was, otherwise it jumps to the next char. But when the char
at $pos is the last one on the line (newline), the bounding box
returned by `bbox` has the full width of the empty area, so if you
click in the right half of that area the insertion cursor will jump to
the next char, which is on the following line (unless you are on the
last line).

For now I'm fixing it with this in place of the first `if`:

if {$bbox eq "" || [$w compare $pos == "$pos lineend"]} {
return $pos
}

So if the mouse click is on the empty area to the right, $pos is the
index of the last char of that text line, and it will stay there. I'm
not sure this is the right way to do it but it is working so far...

Le 04/10/2022 à 01:09, xol odho a écrit :
> After playing around with Tk's lovely text megawidget, I've been
> annoyed by the "line jumping" behavior when you click on the empty
> area to the right of the text.

See:

https://core.tcl-lang.org/tk/tktview?name=b461c70399

This was a lengthy discussion and I never actually made my mind on
changing the behavior or not, and if so, in what version of Tk (and what
version of the text widget - legacy or revised).

Opinions, final arguments and decisive remarks welcome.

Regards,
Francois

That's not a big deal, but I think the current behavior is wrong.
There is no reason why a widget should take decisions for the user.
If I click one line, whatever it is, the insertion point must be
in that line, period. No surprises. Do you want the next line?
Click the next line then.

FWIW.

--
Luc
>>
**************************
On Tue, 4 Oct 2022 07:55:27 +0200, Francois Vogel wrote:

> Le 04/10/2022 à 01:09, xol odho a écrit :
> > After playing around with Tk's lovely text megawidget, I've been
> > annoyed by the "line jumping" behavior when you click on the empty
> > area to the right of the text.
>
> See:
>
> https://core.tcl-lang.org/tk/tktview?name=b461c70399
>
> This was a lengthy discussion and I never actually made my mind on
> changing the behavior or not, and if so, in what version of Tk (and
> what version of the text widget - legacy or revised).
>
> Opinions, final arguments and decisive remarks welcome.
>
> Regards,
> Francois
>

Ok, I just read that Tk ticket page, I really had no idea this had
been reported already. I feel the current behavior is quite
unintuitive, it's one of the first quirks I noticed with the Tk text
widget (which apart from some annoyances like this one, is quite
impressive).

Can't this be fixed in the Tk 8.6 series? Do any apps/users depend on
this behavior? It seems to me like an unexpected secondary effect of
the implementation, not an intended feature and so shouldn't be
depended upon. But I'm a newcomer to Tk, so I really don't know.

There are other things in Tk that cause me more concern though, like
the "<KeyRelease>" semantics clearly broken on X11 (I reported a
ticket already), or the Tk button getting stuck after spacebar pressed
for a few seconds (I didn't file a ticket that one but I inquired
about that on this list a few weeks ago).