On Thu, Dec 12, 2019 at 02:51:18AM -0700, Theo de Raadt wrote: > Marc Espie <[email protected]> wrote: > > > On Wed, Dec 11, 2019 at 01:15:40PM -0700, Theo de Raadt wrote: > > > I'm not sure I understand the goal of the signal handler. > > > > > > sdiff is moving forward through the file, only. If you are in a pager, > > > you want to increase the width for the later output not yet visible? > > > the normal way one does that in programs which don't backtrack and > > > re-output, is by restarting the program. > > > > > > You don't want a mix of shorter, then longer. If you are using a pager, > > > I suspect at least one of the next lines is already be buffered out. So > > > I don't understand how this will create output which looks correct. > > > > > > I think you should remove the signal handler. > > > > Well, in the sysmerge use-case, you see the first line showing the > > $OpenBSD$ prompt usually. That's often when you realize your terminal is > > really small, and you will miss the next lines. The $OpenBSD$ line is > > reasonably unambiguous, as the rev number is fairly prominent. > > > > The next ones will need the space. > > > > Admittedly, it could be smarter, and react during actual user interaction, > > or offer to redraw the last block with a specific command ? > > That you have to dig for such a narrow example really demonstrates > the pointlessness of the signal handler.
I didn't have to dig... it's the specific usecase I have for sdiff3!
