Provide option to render highlights in a different style

[osa1]

difftastic currently uses bold text to highlight diffs.

However, depending on the font and terminal emulator configuration, it's possible for normal and bold text to look similar. In those cases it becomes difficult to see the important parts in a difftastic output.

It would be helpful if difftastic provided an option to use e.g. italic, or underlined etc. text for highlights so that when bold and normal text look similar on a terminal we could choose to render highlighted text with e.g. underlines.

[Wilfred]

difftastic uses pretty much all the colours available on a typical terminal, plus bold, italic, dimmed, and bright colours.

I don't really want to build a theming system, especially before 1.0. It's substantial extra complexity when I'm still trying to get the core logic working well.

Long term, I plan to have HTML output and I'd like to explore 24-bit colour too.

In the meantime, do you have any particular cases in mind that don't look good?

[raphael-proust]

It'd be useful to be able to deactivate syntax highlighting. I've never found a convincing simultaneous use of diff-highlighting and syntax-highlighting: there are always corner cases when the one makes the other unreadable or vice-versa.

So I think it might be useful to have the --color option, but also --color-diff and --color-syntax to suppress some uses of colours but not all.

• --color is the same as before, also --color <VAL> is the same as --color-diff <VAL> --color-syntax <VAL>,
• --color-diff <VAL> sets the diff coloring option only (but leaves the syntax coloring), and
• --color-syntax <VAL> sets the syntax coloring option only (but leaves the diff coloring).

[osa1]

In the meantime, do you have any particular cases in mind that don't look good?

Sorry I missed this. I'm using a semi-bold font, and bold version of the font does not look easy to distinguish from the normal (i.e. semi-bold) version. This makes it difficult to see changes in difftastic outputs as I need to distinguish semi-bold from bold.

[durka]

I love syntax highlighting but I have to agree that the syntax highlighting is distracting from the actual diff highlighting which is the purpose of the tool. Maybe an option to use dimmer colors for the syntax, or use bold/italic for the differences instead of certain syntax elements?

Also, maybe this has changed since the original comment, or it depends on language?

difftastic currently uses bold text to highlight diffs.

I see bold used for syntax, like include.

[egrieco]

Is there any way to just lean on git-delta for the output styling?

I find that the use of background colors to show line and sub-line differences works a lot better than bold with syntax highlighting.

It looks like it might be callable directly as a library at some point: git-delta-lib (though it does say "not ready for use" at the moment)

I'll try to put a pull request together at some point, but probably not for at least a few months. :(

[egrieco]

Been throwing some hours at getting this to work.

Switching the highlight to the background color for only the added and removed words was pretty trivial.

However, getting the whole line to highlight has proven...challenging. I believe that owo-colors is inserting color escapes and resets. This means that in order to highlight the "whole line" we actually have to apply the correct style to the unstyled spans for lines that have changes.

Further, it seems that actual colors are being applied early in the process (probably due to the syntax highlighting) rather than the status (added/removed) for each span. This makes it rather tricky determine which lines need their whole background colored.

Will post a screenshot when I'm in the neighborhood of acceptable. Though I wish the coloring was done with composable style objects. Foreground for syntax, background for changes.

[Wilfred]

See also #265 and #275.

[egrieco]

Still got a few things to fix before I create a pull request, but thanks to yansi's wrapping() function this is doable without rewriting all of the styling logic.

[egrieco]

Wow...that was painful.

Could not get the padding to line up properly for single column sections. It was short on some lines, and strangely, always in multiples of seven characters.

Tried multiple ways to strip hidden characters and several ANSI stripping libraries. The one that finally got things working was cansi. Specifically cansi::categorise_text, then mapping the text of the slices, concatenating all that into a string, and taking its length.

There's got to be a better way to do all this. And some of my code is a bit WET, but I'm done for the night/morning. I'll clean things up a bit and put a pull request together later.

[myitcv]

@egrieco - looking at the above screenshots has prompted me to ask you and others whether anyone has incorporated difft into Gerrit?

[egrieco]

I have not done any such work @myitcv.

Been a bit busy handling students and getting some other coding projects done. Just hoping to get some time to finish up #286 in the next month or so.

[myitcv]

Thanks, @egrieco.

I've started a Gerrit-based conversation at https://groups.google.com/g/repo-discuss/c/BRI-ZB9E0cc for anyone interested.

[unphased]

Just skimmed this. Based on what I saw, i see many attempts to change the fgcolors to bgcolors for indicating changes. I am 100% in support of this, because fgcolors can be exclusively used for syntax highlighting then. Otherwise making only red and green semantically different is incredibly confusing, regardless of ensuring that those colors are never used for actual syntax hl.

Totally understand if @Wilfred isn't trying to prioritize styling right now. But I like others here can't really use a diff that doesn't leverage bgcolors. WRT hacking this in then: I don't understand why it's tricky to convert just red and just green styling into bgcolors from fgcolors. Why not do a plain ansi escape string replacement? I only see difftastic generating red, red bold, red underline, green, green bold and green underline color styles. (side note: hope someone can explain to me difference between bold and underline...?)

[FranklinYu]

I understand that this feature is highly requested, but please provide a switch to opt-out once it is implemented. Hard-coded background color doesn’t work for my setup.

[egrieco]

I'm not teaching anymore, and have cleared a lot of projects from my schedule. It's time to get back to programming!

Thus, getting this cleaned up and merged just made a very large jump up my priority list.

[egrieco]

Trying to find time to hop back into this issue. It looks like there have been some significant code changes to difftastic in the meantime, so I need reacquaint myself with the codebase and redo the changes.

[davidthing]

I tried difft for the first time today. It seems very promising! However, even with --syntax-highlight=off I have to really squint to see to see the changes highlighted in red and green text -- perhaps due to poor eyesight or a bad monitor or something ¯\_(ツ)_/¯. I'm a little embarrassed to admit this, but I'm unable to use this tool without background colors highlighting the changes.

That said, like an earlier comment stated, I totally understand if @Wilfred can't prioritize styling right now! I only wished to share some friendly feedback that this seemingly minor issue is a blocker for me personally.

The docs threw me off for a few minutes because the diff formatting there is closer to the format I wanted:

I now understand that's just a limitation of the tool being used to render the docs, but it took me a bit to realize that difft didn't support background colors.