Re: lib/54329

[Nikhil Benesch <nikhil.benesch%gmail.com@localhost>]

The following reply was made to PR lib/54329; it has been noted by GNATS.

From: Nikhil Benesch <nikhil.benesch%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: uwe%stderr.spb.ru@localhost,
 jordan%cockroachlabs.com@localhost,
 knz%thaumogen.net@localhost,
 christos%zoulas.com@localhost
Subject: Re: lib/54329
Date: Mon, 1 Jul 2019 17:32:45 -0400

 I made a video reproducing this bug using xterm on NetBSD 8.0:
 
     https://www.youtube.com/watch?v=3D_11p93_ylyk
 
 Note that the tc1 program shown in the video was compiled with Jess =
 Thrysoee's
 autotoolized libedit port, v20190324-3.1. (I don't have the NetBSD-foo =
 to
 upgrade the bundled libedit, but I can learn and try to upgrade my VM to
 the latest trunk, if someone thinks that's important.)
 
 It's not shown in the video, but $TERM is set to "xterm".
 
 Responses to a few specific points in line below:
 
 > ...also used `tput cud 5` on the last line and observed no badness.
 
 It's not that badness happens if you run `tput cud 5` with the cursor =
 positioned
 on the last line; it's that nothing happens. This is demonstrated in the =
 video.
 The result is that libedit's cursor position tracking gets out of sync =
 with the
 cursor's actual vertical position; libedit thinks that the cursor has =
 been moved
 down five lines when, in fact, it has not.
 
 > But the code just above is also very clearly checking for that, isn't
 > it?  It may be getting confused about the window size and end up using
 > DO when it shouldn't, but then it's the size tracking that should be
 > fixed (as it likely has other bad consequences), not the innocent
 > bystander.
 
 Based on my debugging, libedit is not tracking the absolute vertical =
 position of
 the cursor. It is tracking only its relative vertical position, relative =
 to
 wherever the cursor is when the editline instance is initialized. So if =
 the
 editing session is started when the cursor is already on the last line, =
 the
 editline.el_cursor.v will be set to "0", which tells us nothing about =
 whether it
 is safe to send T_DO or not.
 
 It's possible that the absolute vertical position is tracked somewhere, =
 but
 nowhere that I've found. Perhaps it would be easy enough to add, but I
 concur with Christos that the optimization is unlikely to be worthwhile =
 on
 modern terminal emulators.