On 4/23/2014 5:11 PM, Jonathan Nieder wrote:
That sounds like a nice feature request for 'less': a marker on the
right margin when --chop-long-lines is in use and a line has been
chopped. I don't see it at
http://www.greenwoodsoftware.com/less/bugs.html#enhance so maybe no
one else has
Junio C Hamano gits...@pobox.com writes:
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.
I am personally in favor of changing the default to drop the S. Silently
Hi,
Matthieu Moy wrote:
I am personally in favor of changing the default to drop the S. Silently
hiding stuff from the user's eyes is really bad. With good coding
standard and reasonable terminal size, it actually doesn't matter.
Just for clarity: no, when we are talking about well formatted
Jonathan Nieder jrnie...@gmail.com writes:
Matthieu Moy wrote:
I am personally in favor of changing the default to drop the S. Silently
hiding stuff from the user's eyes is really bad. With good coding
standard and reasonable terminal size, it actually doesn't matter.
Just for clarity: no,
David Kastrup wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Just for clarity: no, when we are talking about well formatted code,
-S is actually a way better interface.
When we are talking about well-formatted code, -S does not matter either
which way.
Sorry for the lack of clarity. I
David Kastrup d...@gnu.org writes:
d...@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.
Junio C Hamano gits...@pobox.com writes:
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
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
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
On Thu, Apr 24, 2014 at 12:29:21PM -0700, Junio C Hamano wrote:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
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
Jeff King p...@peff.net writes:
I would think it's the opposite. Long lines look _horrible_ without
-S, as they get wrapped at awkward points. Using -S means that long
lines don't bug you, unless you really want to scroll over and see the
content.
I really think the right solution here is
On Thu, Apr 24, 2014 at 02:47:01PM -0700, Junio C Hamano wrote:
And I do agree that the chopped marker would be a very sensible
thing to show in the -S output; I would have chosen $ myself for
that to match an existing practice in (setq truncate-lines t) in
Emacs, though.
Hmm. I do not use
Jeff King p...@peff.net writes:
On Thu, Apr 24, 2014 at 12:29:21PM -0700, Junio C Hamano wrote:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
Traditionally, because the tool grew in a context of being used in a
project whose participants are at least not
On Thu, Apr 24, 2014 at 11:48:30PM +0200, David Kastrup wrote:
I really think the right solution here is to teach less to make it more
obvious that there is something worth scrolling over to. Here's a very
rough patch for less, if you want to see what I'm thinking of.
Still useless. I'm
Jeff King p...@peff.net writes:
On Thu, Apr 24, 2014 at 11:48:30PM +0200, David Kastrup wrote:
I really think the right solution here is to teach less to make it more
obvious that there is something worth scrolling over to. Here's a very
rough patch for less, if you want to see what I'm
Hi,
David Kastrup wrote:
Jeff King p...@peff.net writes:
There are two questions here:
1. Can less do a better job of indicating what's in the input when -S
is in effect?
2. What should get put into $LESS by default?
I was specifically addressing (1). Your comment does not help
hello list,
as mentioned earlier on IRC, I'm a bit concerned about the default LESS flags
used by git.
The S option causes git to cut off everything to the right
Consider this diff, printed by `git diff`
#!/usr/bin/env python
-print('foo')
+print('bar')
Looks ok to
(cc-ing Mark Nudelman, less maintainer)
Hi,
d...@mailtor.net wrote:
Consider this diff, printed by `git diff`
#!/usr/bin/env python
-print('foo')
+print('bar')
Looks ok to merge and run.
But, after disabling the pager:
Unfortunately there are other kinds of subtle
d...@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
18 matches
Mail list logo
