When `--color-only` is used, colors don't extend to the whole line

[da-x]

When using --color-only, the color only ends at the last line's non-white-space character, instead of extending to fill also the blank space after to the last character to the right side of the terminal.

Compare:

With:

p.s. I'm author of da-x/fancydiff. I think delta is very cool, and I'd longed for abandoning fancydiff for a better option.

[dandavison]

Hi @da-x, fancydiff looks cool! It's a bit more ambitious than delta in some ways -- I'm very happy that I've got syntect and the sublime syntax definitions. If you ever feel like writing git diff processing code in Rust instead of Haskell, we have some open issues here :)

So, --color-only is working as intended I believe. It's job is to "not alter the input in any way other than applying colors", so that includes not right-padding with spaces . AFAIK the only way that delta can apply a background color to the right-hand edge of the terminal is by right-padding with space characters and applying the background color to the spaces.

On the plus side, --color-only is equivalent to

--keep-plus-minus-markers --width variable --tabs 0 --commit-style plain \
--file-style plain --hunk-style plain

so you should be able to achieve the effect you want by using some subset of those options directly and not using --color-only. (It's --width variable that you want to get rid of.)

[da-x]

@dandavison I'm quite positive that fancydiff achieves this without space padding. I'll check how

[da-x]

echo '\x1b[48;2;40;100;200mTest\x1b[K'

Yeah, it's the \x1b[K ANSI control code.

[da-x]

Ah, it's not enough. I also pass the following environment to less: LESSANSIENDCHARS=mK.

[dandavison]

Wow, thanks! I had never looked into it. This seems to be potentially a big advance. It might be perceptibly more efficient for the terminal emulator than having to handle a ton of space characters, and it may simplify some of the terminal-width accounting code. By default, delta spawns a child less process, so we should be able to set that env var. As far as you know this is well supported / totally standard in terminal emulators?

Here's a screenshot showing some playing around with this (iTerm2):

@lzybkr should this all work fine with (your) less.exe on Windows and common Windows terminal emulators?

[lzybkr]

@dandavison - I think \x1b[K should work fine with Windows 10 terminal emulators and with my fixes to less.exe.

[dandavison]

Thanks very much @da-x and @lzybkr. The master branch now uses \x1b[K and sets LESSANSIENDCHARS in the child less process. ref #155

[da-x]

Thanks! Looks like we have one bug with this - if the emphasized-in-diff is at the end of the line, the rest of the line is colored with the emphasized color instead of the modified line color.

[dandavison]

Good catch! I believe that's fixed in master via #167.

(I noticed another similar bug in that I was no longer terminating with a reset sequence; it didn't affect the behavior of my terminal emulator but I believe it is correct to reset at the end of each line, it is what ansi_term::ANSIString does, and it did cause a problem when using Delta with Magit in Emacs)