On Mon, May 20, 2024 at 09:45:51PM +0200, Dragan Simic wrote: > > Another, ulteriour, motive here behind this suggestion is to > > encourage users to work with smaller hunks. Being able to scroll > > around and view lines on demand (i.e. use of pager) is one thing. > > Being able to view all relevant lines at once (i.e. not wasting > > vertical screen real estate and making things fit on one screen) is > > very different and much nicer. > > There's another thing to consider, which makes the introduction of > "P" as the new option even more desirable. Let me explain. > > With the upcoming changes to the way less(1) as the pager works, > which was already discussed at length and even required new features > to be implemented in less(1), [1] displaying anything through less(1) > will not leave an accessible scrollback in the terminal emulator. > Only one screen worth of text will be displayed, even after quitting > less(1). That's what we have to do, to fix age-old issues with the > pager-generated scrollback that easily gets corrupted and actually > becomes misleading. This feature can be annoying even with current versions of less, depending on your $LESS variable. If you don't set "F" you'll get a pager for short inputs, and if you don't set "X" then even small hunks are cleared from the screen while we ask about them. So this definitely needs to be configurable, and I'd be tempted to say it should be off by default, just because we don't know how the user's pager will behave when invoked for multiple short snippets like this (it might not even be "less", after all). I don't think setting pager.add is enough here. You'd also need to set pager.checkout, pager.reset, and so on, since their interactive modes all invoke the same code. We'd presumably want a single config option (and possibly even one that could be set to a distinct pager command for this context, rather than the usual one). -Peff
