Re: Harmful LESS flags

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Harmful LESS flags

From: David Kastrup <hidden>
Date: 2016-06-15 23:00:48

d9ba@mailtor.net writes:
It would be nice if we could change the flags to either

 a) avoid cutting off
 b) indicate something has been cut off (<- I prefer this)

I assume there are more people with a similar workflow who're still
unaware of this feature.

I would joke about how 3 letter agencies introduced this flag to
backdoor open source projects, but, well..
Most terminals are wider than three letters.

Still, it is a total nuisance.  I am constantly doing

-S RET

on my git output.  This should be left alone as an entirely personal
preference quite unrelated to Git.  There is no point in having Git
configure a default different from what is used elsewhere.

-- 
David Kastrup

Re: Harmful LESS flags

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:49

David Kastrup [off-list ref] writes:
d9ba@mailtor.net writes:
quoted
It would be nice if we could change the flags to either

 a) avoid cutting off
 b) indicate something has been cut off (<- I prefer this)

I assume there are more people with a similar workflow who're still
unaware of this feature.

I would joke about how 3 letter agencies introduced this flag to
backdoor open source projects, but, well..
Most terminals are wider than three letters.
I am having a hard time to decide if you genuinely misread what you
are responding to, or if you are joking.  If the latter, I find the
joke mildly funny in a twisted way ;-)

But the tangent aside...
Still, it is a total nuisance.  I am constantly doing

-S RET

on my git output.  This should be left alone as an entirely personal
preference quite unrelated to Git.  There is no point in having Git
configure a default different from what is used elsewhere.
I almost agree with the general principle of the last sentence, but
with a bit of reservation.  The default value for LESS (i.e. when
the user does not have any) we pass is FRSX, and the Porcelain
output these days is colored by default.  If we don't set a default
at all, the end-user experience for a newbie will be bad, especially
without "R".

Among the other three, F and X are to avoid a short output (e.g "git
show" on a one-liner with a short explanation) from asking for
confirmation to leave the pager and from clearing the screen upon
leaving the pager, and are generally accepted as good things (or at
least, we haven't seen much issue raised after we started passing
the default LESS for those who do not have their own in their
environment).

Use of S is very subjective.  While I personally do appreciate that
we have it by default, I can perfectly well understand why some
people do not want to see it in the default.  The best we can do is
to arrange so that people from one of the camps have their favorite
out of the box and those from the other camp need to tell Git that
they want to (or do not want to) fold long lines.

Traditionally, because the tool grew in a context of being used in a
project whose participants are at least not malicious, always having
to be on the lookout for fear of middle-of-line tabs hiding bad
contents near the right edges of lines has never been an issue.  If
somebody brought up a potential issue of such mode of attack back
then, Linus may have chosen the default differently.  I may have
myself chosen not to have S, if I were the maintainer when the LESS
default was originally introduced, and had I been made aware of this
issue.

I am not opposed to changing the default in the longer term, as long
as we have a solid transition plan to ensure that it won't disrupt
and/or upset existing users too much.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help