On Tue, Dec 11, 2018 at 01:55:09PM -0500, George King wrote:
> I just noticed that while `wsErrorHighlight = none` fixes the problem
> of extra green codes for regular diff, it fails to have any effect
> during interactive `git add -p`.
This is due to the way add--interactive invokes diff. It use
On Tue, Dec 11, 2018 at 11:41:18AM -0500, George King wrote:
> I first started playing around with terminal colors about 5 years ago,
> and I recall learning the hard way that Apple Terminal at least
> behaves very strangely when you have background colors cross line
> boundaries: background color
I just noticed that while `wsErrorHighlight = none` fixes the problem of extra
green codes for regular diff, it fails to have any effect during interactive
`git add -p`.
> On 2018-12-11, at 11:41 AM, George King wrote:
>
> I first started playing around with terminal colors about 5 years ago,
I first started playing around with terminal colors about 5 years ago, and I
recall learning the hard way that Apple Terminal at least behaves very
strangely when you have background colors cross line boundaries: background
colors disappeared when I scrolled lines back into view. I filed a bug t
On Tue, Dec 11 2018, Jeff King wrote:
> On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
>
>> > Context lines do have both. It's just that the default color for context
>> > lines is empty. ;)
>>
>> The content itself can contain color codes.
>>
>> Instead of unconditionally resett
Peff & Stefan, thank you for the feedback. For my purposes, I am content to
rely on gitconfig to reduce the colors to something that I can parse without
losing information. Since my first email I have found that `wsErrorHighlight =
none` gets rid of the problematic extra green highlights in the
On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
> > Context lines do have both. It's just that the default color for context
> > lines is empty. ;)
>
> The content itself can contain color codes.
>
> Instead of unconditionally resetting each line, we could parse each
> content lin
> (For the Git project itself, we long ago realized that putting raw color
> codes into the source is a big pain when working with diffs, and we
> instead use tools like t/test-lib-functions.sh's test_decode_color).
And also we hid the colors behind #defines and such.
> > * Context lines do not b
On Fri, Dec 07, 2018 at 07:09:58PM -0500, George King wrote:
> My goal is to detect SGR color sequences, e.g. '\x1b[32m', that exist
> in the source text, and have my highlighter print escaped
> representations of those. For example, I have checked in files that
> are expected test outputs for too
Hello, I have a rather elaborate diff highlighter that I have implemented as a
post-processor to regular git output. I am writing to discuss some difficult
aspects of git diff's color output that I am observing with version 2.19.2.
This is not a regression report; I am trying to implement a new
10 matches
Mail list logo
