Re: why does git set X in LESS env var?

> On Wed, Oct 11, 2023 at 03:23:20PM -0700, Junio C Hamano wrote:
> 
>> Christoph Anton Mitterer <calestyo@scientia.org> writes:
>> 
>> > But I still don't get from that why X would be needed?
>> >
>> > My less manpage documents it as:
>> >> -X or --no‐init
>> >>     Disables sending the termcap initialization and deinitialization
>> >>     strings to the terminal.  This is sometimes desirable if the
>> >>     deinitialization string does something unnecessary, like clearing
>> >>     the screen.
>> >
>> > Is it to avoid clearing the screen?
>> 
>> I think that was the reason we added it back in 2005.  In any case,
>> asking "why" is not a useful use of anybody's time, because it is
>> very unlikely to change in the official version we ship, and because
>> it is so easy for any individual who does not like it to drop by
>> exporting the $LESS environment variable.
> 
> I agree it is probably not worth changing now, but I think the history
> here is a little interesting.
> 
> Yes, I think "X" was added because less would clear the screen after
> exiting, and with "F" this meant you'd see nothing. Here's a thread 
> from
> the same time period discussing it:
> 
> 
> https://lore.kernel.org/git/cc723f590610210623sbee2075i5f2fd441cceb84ae@mail.gmail.com/
> 
> But I also think this was a pretty well-known annoyance with "less" 
> back
> then.
> 
> However, I can't seem to reproduce it now! Digging into the history and
> the changelog, this note is in "changes between less versions 487 and
> 530":
> 
>   Don't output terminal init sequence if using -F and file fits on one
>   screen.
> 
> So it seems like the problem has been fixed inside less for recent
> versions. And in theory we _could_ drop "-X" if it is causing problems.
> That version of less is ~5 years old. It does seem a little premature 
> to
> assume everybody has it. And as you say, if there are people who really
> care about their LESS options, it is easy for them to override it.