No way to prevent screen clearing on quit/exit without switch (after launch)

[Chealer]

Version 598 introduces a proper way to redraw the screen when less is exited. This feature is unfortunately only enabled by the new --redraw-on-quit switch. If the user only realizes keeping the screen is relevant once less is already open, by default, there is no way to redraw besides exiting, adding the switch, relaunching, reaching the relevant zone and then exiting again.

While @gwsw's 2021-09-05 comment in ticket #36 explains how a keypress can achieve that, this feature is useful enough that such a keybinding should be provided by default. I have no strong opinion on which key [combination] it should be, although a capital "Q" sounds quite intuitive to me.

[bew]

For the record, I'm using Alt-q for this, reading it as alternative quit (I'm using it a lot since it's available 👌)

[gwsw]

there is no way to redraw besides exiting, adding the switch, relaunching, reaching the relevant zone and then exiting again.

I don't understand this. While in less, if the user decides they want to redraw on exit, they would simply need to type --redraw-on-quit and then exit. It doesn't seem terribly onerous to me, especially since only the first 4 characters are necessary, but as with any option, the user can add an entry to their lesskey file to reduce the number of keystrokes necessary.

Also note that the usefulness of this option depends on the terminfo entry for the user's terminal. If the terminfo doesn't use an alternate screen, --redraw-on-quit is worse than useless and would never be used.

BTW, "Q" is already assigned a function, so it would not be good to reassign it and possibly confuse users who are already using it for its current function. If a new command were added to less, it would have to be assigned to a currently unassigned sequence.

[Chealer]

Ooh... Unix has lots to offer, so I shouldn't be surprised I'm only learning of less's basics after 20 years using it! Thank you very much @gwsw, great to learn that.

I believe offering a command would be best. I appreciate that changing the behavior of existing commands can be delicate, but if an uppercase "Q" has the same function of exiting as the lowercase "q" and the replacing function would also exit, I consider the stakes as quite limited. Additionally, if "Q" has the same effect as "q", I would imagine that few people use it (I for one didn't know it existed even though I used "q" thousands of times). If that's an issue though, ":qr" or ":rq" would seem nearly just as good to me.

That being said, I am apologizing and closing this report as invalid and letting those motivated possibly open a new report about adding a command.