#3024 Scrolling up with elided text doesn't play nice

[Talvo]

Create a basic text widget with some elided text, for example:

pack [text .t -yscroll ".s set"] [scrollbar .s -command ".t yview"] -side left -fill y
.t tag config hide -elide 1
foreach x [list 0 1 2 3 4 5 6 7 8 9 0] {
.t insert end "foo\nfoo\nfoo\nfoo\nfoo\nfoo\n"
.t insert end "bar\nbar\nbar\nbar\nbar\nbar\n" hide
}

Then scroll the text a line at a time, either by clicking in the text widget and using the up/down arrow keys, or with

.t yview scroll 1 unit
.t yview scroll -1 unit

The text scrolls down without any problem, but when scrolling up again, it pauses whenever it gets to an ellided line, causing the scroll action to have no visible effect. (tested on 8.5.9 and 8.6b1 on Windows XP and Win 7)

[Francois VOGEL]

I could see the issue on 8.5.9 with

t yview scroll 1 unit
.t yview scroll -1 unit

but not with the keyboard. Could you please explain again how you trigger the bug with the keyboard?

Also, must check whether this can be reproduced with the latest sources (8.5.12 at least), since I have fixed issues when moving the cursor in elided text a few months ago, see:

http://sourceforge.net/tracker/?func=detail&aid=3021557&group_id=12997&atid=112997

[Talvo]

Ahh, it seems to only break using the keyboard if you omit the final \n from both of the insert lines, which also causes wish to hang, as mentioned in the ticket you linked.

[Francois VOGEL]

Here is an update on the matter:

I have investigated this issue quite deeply. It's not easy to get it right.

I have made to the conclusion that FindDLine is wrong: it does not account for the possibility of elided newlines. This is the root cause of several problems when moving the cursor in elided text, clicking in text widgets within elided ranges, selecting text, absence of cursor blinking and so on.

Fixing FinDLine in this regard is however not enough by itself. It is used in a number of places in the text widget code and all these places must be checked/updated to make sure elided newlines are taken into account there as well (they are currently not).

This takes time and is also in a rather low prio in my to-do list...

[Francois VOGEL]

Another incarnation of the apparently same bug hit Tablelist and is described here:

https://groups.google.com/d/msg/comp.lang.tcl/hBIXFmZ-MpY/wXygfdVVLfUJ