[feature] Add file modify state to output for less pre-seeding

[niedzielski]

I just saw delta on Hacker News! Congrats!

delta looks super useful but I'm missing the pre-seed feature of diff-so-fancy which allows one to page through each file by tapping n. I've found the following less options work well but it needs file state delimiters (e.g., commit, added, deleted, modified, ...):

# Warning: silly regex ahead!
pager = delta --commit-style box --tabs 2 | less -iRFXx2 '+/^(commit|added:|deleted:|modified:|renamed:|stash@\\{[0-9]+\\}:) | changed file mode from [0-9]{6} to [0-9]{6}$'

A cursory test of delta shows everything but file modifies are identified because these file state demarcations are omitted. I didn't see any options for adding the markers back in so this is a feature request to enable that functionality!

As a workaround, I think I could use a dash (─) regex but I really want the highlight to be on the filename itself, not the dash, as the line above the match is cut off by the terminal (the filename in this case).

Thank you so much for this awesome tool! It looks great! 👍

Edit (2020-04-27): Actually, I think my first report was terrible. Only file modify markers (both modified and changed file mode) are omitted. The others seem to be present. Updated.

[dandavison]

Hi @niedzielski, thanks! Absolutely, I need to fix this. There's another request for it, where I have suggested a workaround: #50 but really I think delta should just add the options being requested already :) In that other ticket I mentioned the possibility of using unicode characters in place of the standard modified, renamed, etc. Even if we did that I would definitely want to have the option to use the standard strings, so it's just a question of what defaults are. I'm somewhat attracted by offering unicode characters since a design principle of delta is basically that its output is for humans, not for machines. (At least, if it's going to a tty).

[niedzielski]

Thanks for the fast response and sorry I missed that ticket. I will close this as a duplicate of #50.

I think Unicode strings would work fine for my use case (and look nice too!)? I shall eagerly await #50's resolution whenever it may come!