Make addition/deletion of empty lines visible

[Quoor8ee]

I love diff-so-fancy. But since its displaying is so literal (it does not add visible control characters), I can't see what is going on with empty lines (added or removed). I quickly got used to the beautiful and fine-grained colouration of the diffs (mostly using for hg diff), but the silence about empty lines holds me back from deploying everywhere.

I haven't come up yet with a clever idea how this could look like.

[scottchiefbaker]

I'm confused... DSF already marks added/removed blank lines:

https://github.com/so-fancy/diff-so-fancy/blob/master/README.md#markemptylines

[Quoor8ee]

Yes, but this is a git option. But DSF might be of use besides git. But then it won't magically parse git configuration to look up tunables in ~/.gitconfig.

[scottchiefbaker]

I'm not sure exactly what you're asking for.

[Quoor8ee]

echo > file_tracked_by_mercurial
hg diff | diff-so-fancy   # should somehow show up the additional newline in a discernible manner

[scottchiefbaker]

Our markemptylines lines options will highlight with a green/red box at the beginning of a line any blank line that was added or changed. It's not specific to git. Any diff that includes an empty line that starts with either - or + will work.

https://github.com/so-fancy/diff-so-fancy/blob/master/README.md#markemptylines

[Quoor8ee]

I'd LOVE to confirm this, but it does not agree with my observations.

MWE:

$ cd $(mktemp -d)
$ hg init
$ touch file
$ hg add file
$ hg ci -m "1"
$ echo >> file
$ hg diff | cat
diff -r 30faf110cd13 file
--- a/file      Fri Apr 10 01:07:27 2020 +0200
+++ b/file      Fri Apr 10 01:07:50 2020 +0200
@@ -0,0 +1,1 @@
+
$ hg diff | diff-so-fancy
──────────────────────────…
modified: file
──────────────────────────…
@ file:1 @

$ grep -B 1 markEmptyLines ~/.gitconfig
[diff-so-fancy]
        markEmptyLines = true
$ diff-so-fancy --version
Diff-so-fancy: https://github.com/so-fancy/diff-so-fancy
Version      : 1.2.6
$ pacman -Qi diff-so-fancy-git | grep Version
Version                  : 1.2.7.r1.g05e2a1a-1

DSF seemingly tries to do something in the right direction, sincet the shell cursor colour has turned green in the next prompt. But sorry, nothing is displayed there. Local configuration mess is an improbable cause, since the same behaviour shows up for a newly created user.

Dunno if packaging can do any harm here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=diff-so-fancy-git

[scottchiefbaker]

Is the issue with SINGLE line files like you mention, or all files that have a add/removal of an empty line?

I can assure that d-s-f shows add/removes of empty lines. I use it all the time. It's even in the screenshot on the repo main page (bottom right of the screenshot).

[Quoor8ee]

I have tried all combinations of adding and/or removing single or multiple empty lines in single or mutiple files of arbitrary length between 0 and hundreds of lines. I have never seen a highlighted line as the one in your screenshot.

Btw multiple platforms are affected: behaviour is identical on Arch Linux, Debian and FreeBSD, and KDE Konsole, xterm, xfce4-terminal and Linux tty.

[Quoor8ee]

OK, DSF if used as a diff formatter for git, apparently has some silent extra assumptions about the diff format, than when it is used in standalone mode:

https://i.imgur.com/DQnUtmS.png

At least now I've finally seen the intended behaviour, and it is not a terminal display issue. But this means as well that DSF is not a fixed point of its own diff I/O.

Expected outcome: git diff with DSF configured in ~/.gitconfig, and git diff | diff-so-fancy should look identical.

[OJFord]

@Quoor8ee That's because the pager (which happens to be diff-so-fancy) is disabled when you pipe (cf. git diff | cat) and then you re-colour with diff-so-fancy directly.

When you call it directly, it's not using your .gitconfig, and so there is no markEmptyLines = true option being considered.

[Quoor8ee]

Thanks for clarification, I suspected something like that. I have to assume this is intentional, and current diff-so-fancy is not able to read its config when not called by git, hence not usable as a general-purpose diff formatter?

Adding --color to git diff (like DSF's CLI proposes) does the trick by adding colour escape sequences into the stream. But then DSF is relying on git's own non-ASCII diff output, which is (a mild form of) trapping into vendor lock-in, and ignore standards for a bit (if any) of convenience.

Don't get me wrong, I like DSF a lot, but it is not as drop-in as it could (and should, IMHO) be to integrate into workflows of people who cannot freely choose git as their RCS.

[scottchiefbaker]

d-s-f should be used to format git diff or diff -u output. Anything beyond that is just extra.

git diff HEAD~4
cat diff.txt | diff-so-fancy
diff -u one.txt two.txt | diff-so-fancy

Are all supported formats. We also have simple mercurial support as well.

[Quoor8ee]

That's a bummer. Two of these three “supported formats” don't work, or please tell me what else might have gone wrong here:

I'm mildly irritated that there wasn't even an attempt (or at least it was not shared with public) to reproduce the issue.

Edit: I re-read the docs, and at least the diff.txt case can be circumvented by creating diff.txt as an escape-sequence laden git diff --color output. The third case persists. If it had worked at any time, I'd never had the need to file this bug report.