Full-width bars are one character too long

[dandavison]

Full-width bars are one character too long

[dandavison]

Thanks for the report @nedbat. That leading whitespace is indeed not supposed to be there. I'd definitely like to get to the bottom of this. However, it might require a bit of back and forth, because I haven't managed to reproduce it yet.

The short version is that it's looking to me like your system, when it encounters the ANSI escape code at the beginning of the problematic lines, is causing some white space to be rendered (as if it were a space character), and also switching color as the ANSI code dictates. Whereas mine is just switching color.

I've tried iTerm2 3.3.4, 3.3.3, 3.3.2. I haven't found a link to the beta that you're on yet. Could you perhaps try 3.3.4?

Here's how the beginning of --compare-themes renders for me. So for me, the filename, the horizontal line and the ensuing diff hunk all appear to start in the first column¹, whereas for you it looks like those lines start in the second column:

The main clue here seems to be that the problematic lines are the ones that start with an ANSI escape code; the initial line ("Theme: 1337") lacks any ANSI codes and starts in the first column for both of us.

$ delta --compare-themes 2>/dev/null | head -n10 | cat -A
$
Theme: ^[[1m1337^[[0m$
$
$
^[[34mtests/data/hello.c^[[0m$
^[[34mM-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@M-bM-^TM-^@^[[0m$
^[[34m1^[[0m$
^[[38;2;248;248;242m ^[[38;2;255;94;94m#include^[[38;2;248;248;242m ^[[38;2;255;255;255m<^[[38;2;251;227;191mstdio.h^[[38;2;255;255;255m>^[[38;2;248;248;242m                                                           $
^[[38;2;248;248;242m                                                                              $
^[[38;2;248;248;242m ^[[38;2;251;223;181mint^[[38;2;248;248;242m ^[[38;2;140;218;255mmain^[[38;2;248;248;242m(^[[38;2;251;223;181mint^[[38;2;248;248;242m ^[[38;2;252;147;84margc^[[38;2;248;248;242m, ^[[38;2;251;223;181mchar^[[38;2;248;248;242m ^[[38;2;255;94;94m**^[[38;2;252;147;84margv^[[38;2;248;248;242m) {                

The versions I've tried are:

MacOS: 10.14.5
iTerm: {3.3.4, 3.3.3, 3.3.2}
delta: 0.0.9
git: 2.18.0

---

¹ While the filename tests/data/hello.c starts in the first column for me, the subsequent code in the diff hunk itself starts in the second column. This is how delta is currently supposed to behave. It's because it replaces the traditional unified diff +/- markers with a space. For you, the diff hunk code appears to start in the third column.

[nedbat]

Hmm, I didn't think delta used less, but the problem seems to be my LESS environment variable. I have LESS=-isFJRQWX. If I use delta --compare-themes 2>&1 | head -n10, it looks fine, and if I use LESS= delta --compare-themes it looks fine.

[dandavison]

Ah, excellent, thanks for figuring that out. Yes, delta does spawn a less process for paging functionality. (I actually took that code pretty much directly from bat). That code already does some overriding of the PAGER env var value under certain conditions. It should be possible to improve the experience for delta users here. Perhaps I can improve the overriding, or warn the user that their environment variable values may not be optimal for delta.

[nedbat]

A simple way to fix this would be to subtract one or two from the width for "full-width" bars. No one will care if they don't go quite to the right edge.

[dandavison]

OK, good call, I'll do that.

(For any future readers of this issue, it was less -J i.e. --status-column that was adding the extra column on the left.)

[dandavison]

OK, this should be fixed in version 0.0.13.