On Tue, Jun 13, 2017 at 4:42 PM, Jonathan Tan wrote:
> On Mon, 12 Jun 2017 19:31:51 -0700
> Stefan Beller wrote:
>
>> When using git-blame lots of lines contain redundant information, for
>> example in hunks that consist of multiple lines, the metadata (commit name,
>> author, timezone) are repea
On Mon, 12 Jun 2017 19:31:51 -0700
Stefan Beller wrote:
> When using git-blame lots of lines contain redundant information, for
> example in hunks that consist of multiple lines, the metadata (commit name,
> author, timezone) are repeated. A reader may not be interested in those,
> so darken them
Stefan Beller writes:
> On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> But you do not want to (yet)? The goal is not to tell you where the bounds
>>> are, but the goal is to point out that extra care is required for review of
>>> these particular 3 lines
On Tue, Jun 13, 2017 at 10:48 AM, Junio C Hamano wrote:
>
> I never said "start and end" (you did). I just wanted the boundary
> of A and B and C clear, so I'd be perfectly happy with:
>
> context
> +A dim
> +A dim
> +A highlight #1
> +C
Stefan Beller writes:
> On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> But you do not want to (yet)? The goal is not to tell you where the bounds
>>> are, but the goal is to point out that extra care is required for review of
>>> these particular 3 lines
On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> But you do not want to (yet)? The goal is not to tell you where the bounds
>> are, but the goal is to point out that extra care is required for review of
>> these particular 3 lines.
>
> And when you _can_ help u
Stefan Beller writes:
> But you do not want to (yet)? The goal is not to tell you where the bounds
> are, but the goal is to point out that extra care is required for review of
> these particular 3 lines.
And when you _can_ help users in that "extra care" by pointing out
where the boundary is, w
On Tue, Jun 13, 2017 at 10:19 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Here is what currently happens:
>>
>>>
>>> context
>>> -B dim oldMoved
>>> -B dim oldMoved
>>> -B highlight oldMovedAlternative
>>>
Stefan Beller writes:
> Here is what currently happens:
>
>>
>> context
>> -B dim oldMoved
>> -B dim oldMoved
>> -B highlight oldMovedAlternative
>> -A highlight oldMovedAlternative
>> -A
On Tue, Jun 13, 2017 at 10:00 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> * As you have an individual color setup, maybe you can fix this
>> for you by setting the appropriate slots to your perception of
>> dimmed?
>
> I do not think it is possible with only {new,old}{,alternative}
Stefan Beller writes:
> * As you have an individual color setup, maybe you can fix this
> for you by setting the appropriate slots to your perception of
> dimmed?
I do not think it is possible with only {new,old}{,alternative} 4
colors.
Consider this diff:
context
-B
On Tue, Jun 13, 2017 at 8:25 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When using git-blame lots of lines contain redundant information, for
>> example in hunks that consist of multiple lines, the metadata (commit name,
>> author, timezone) are repeated. A reader may not be intereste
Stefan Beller writes:
> When using git-blame lots of lines contain redundant information, for
> example in hunks that consist of multiple lines, the metadata (commit name,
> author, timezone) are repeated. A reader may not be interested in those,
> so darken them. The darkening is not just based
When using git-blame lots of lines contain redundant information, for
example in hunks that consist of multiple lines, the metadata (commit name,
author, timezone) are repeated. A reader may not be interested in those,
so darken them. The darkening is not just based on hunk, but actually
takes the
14 matches
Mail list logo
