Re: lib/54329

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/54329
Date: Tue, 2 Jul 2019 18:14:05 +0000

 On Mon, Jul 01, 2019 at 09:35:02PM +0000, Nikhil Benesch wrote:
  >  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.
 
 This appears to be the case, inasmuch as nothing ever assigns
 el_cursor.v, only adjusts it, but I still can't reproduce the problem.
 
 If you start this as your terminal session, e.g. with xterm -e:
 
 #!/bin/sh
 for x in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do echo $x; done
 exec sh -o emacs
 
 the libedit in sh should initialize a long way from the top of the
 screen, but I don't see the reported behavior in either xterm or tmux,
 even though both do nothing when you run tput DO 5 on the bottom line.
 (With a libedit binary from November.)
 
  >  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.
 
 I'd expect other things to mess up if it's off. Even if it never
 issues an absolute cursor move, there are still things like special
 treatment of the last character on the last line to go wrong. So it
 should really be reading the cursor position from the terminal at
 initialization.
 
 I think I've discovered one, which is that when started this way, if
 you make an input line that's nearly as large as the whole screen,
 move to the middle of it and hold down 'a' to start inserting
 characters, when the beginning of the line scrolls off the top of the
 screen the cursor doesn't move with it. But it doesn't seem to happen
 if started normally. I think. This is presumably from the overflow
 code in re_fastputc in refresh.c, which tests el_cursor.v against
 t_size.v...
 
 Also, very broken things happen if you cause libedit to initialize
 when it's not at column 1.
 
 
 (hi Nikhil!)
 -- 
 David A. Holland
 dholland%netbsd.org@localhost