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

> On 2023-11-02 15:19, Dragan Simic wrote:
>> On 2023-11-02 14:19, Thomas Guyot wrote:
>>> On 2023-11-02 02:48, Dragan Simic wrote:
>>>> We've basically reached some kind of an agreement about the need for 
>>>> a
>>>> good solution, which turned out to be rather complex as a result of
>>>> being quite universal and extensible, which was required for it to,
>>>> hopefully, be accepted into less(1).  Also, the author of less(1) 
>>>> seems
>>>> to be quite busy with some other things, and he prefers to implement 
>>>> new
>>>> features himself.
>>>> 
>>>> We've also agreed on another new feature for less(1), hopefully, 
>>>> which
>>>> isn't exactly related, but should be quite useful.  It's about the
>>>> secure mode for less(1).
>>> 
>>> Feel free to cc me on your next correspondence. If there are mailing
>>> lists archives for the thread I'll fetch them as needed. We have at
>>> least one working term/switch combination, which IMO is a better 
>>> start
>>> than nothing :)
>> 
>> Please test the "--redraw-on-quit" option, AFAICT that's all we need
>> (plus the already mentioned other improvements to less(1), to avoid
>> the version-dependent workarounds), and the distributions will
>> eventually catch up with the newer versions of less(1).  If the whole
>> thing has worked for decades as-is, it can continue working that way
>> for a year or two until the packages get updated.
>> 
>> There's actually no two-way mailing list for less(1), the entire
>> project is pretty much a one-man show, so to speak.  There's a GitHub
>> page that allows issues to be submitted, but I didn't use that, so I
>> exchanged a few private email messages instead with the author.  I've
>> already summed up the important parts of those messages.
> 
> Good news! :)  The author of less(1) has implemented a couple of new
> features that should resolve our issues with the pagination.  The
> improvements for the secure mode of less(1) have also been
> implemented.  I'll test all that in detail, and I'll move forward with
> implementing the required changes in Git.
> 
> It seems that a new version of less(1) may also be released rather
> soon, so we might be on a good way to have these longstanding issues
> resolved in the upcoming releases of Git and less(1).  It will take
> time for the Linux distributions to catch up with their package
> versions, but also the rolling-release distributions will get the new
> versions with no delays.