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 t
David Kastrup wrote:
> Jonathan Nieder 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 believe wel
Jonathan Nieder 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, when we
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 formatt
Junio C Hamano 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
hiding stuff from th
Hi,
David Kastrup wrote:
> Jeff King 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 h
Jeff King 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 thin
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 useles
Jeff King writes:
> On Thu, Apr 24, 2014 at 12:29:21PM -0700, Junio C Hamano wrote:
>
>> David Kastrup writes:
>>
>> > Junio C Hamano writes:
>> >
>> >> Traditionally, because the tool grew in a context of being used in a
>> >> project whose participants are at least not malicious, always havi
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
Jeff King 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 to te
On Thu, Apr 24, 2014 at 12:29:21PM -0700, Junio C Hamano wrote:
> David Kastrup writes:
>
> > Junio C Hamano 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
Junio C Hamano writes:
> David Kastrup writes:
>
>> Junio C Hamano 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
>>>
David Kastrup writes:
> Junio C Hamano 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
Junio C Hamano 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 been an issue.
David Kastrup 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 feat
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
(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 s
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 mer
19 matches
Mail list logo
