🚀 Include option to expose file-level change as hunk

[mrjoel]

I'm exploring ways to further compact vertical space. As mentioned in #731 I'm revisiting not showing file entries at all. It may end up being a fools errand, but so far it seems to mainly works reasonably well for edits. What doesn't work well is that file-level changes are of course not shown at all. So far I've identified the below information elements (there may well be more) which are completely blocked from view when using the settings file-style = omit and hunk-header-style = file line-number syntax.

• file rename (even worse/misleading with rename and changes combined)
• submodule changes
• execute bit changes

Additionally, the following elements are inferable but not exactly clear.

• file addition (diff shows only added lines starting from line 1, would prefer explicit "added: "
• file deletion (diff shows only deleted lines starting from line 0, would prefer explicit "removed: "

Would it be straight forward in the state machine handling to make the full file-level content text available within the hunk-header-style config option, similar to how the file attribute currently includes just the filename? I'm just experimenting, but think that a configuration which I would like would be something like the following. The main tradeoff which I'm not sure how it'll pan out is that this would make things more compact for few (1-2) changes across many files, at the risk of possibly slightly increasing space used for many changes within a single file. That is at least compared to my current configuration of showing file header and using hunk-header = omit as I'm doing now.

I'm roughly thinking something like the following, where file-full is the entire text content for what would be shown in the outer file header. I can't think of any case where it would be useful to use both file and file-full, but having the option may be beneficial.

hunk-header-style = file-full line-number syntax

In order to have this be fully effective, I think delta would also need to emit meta-hunks of its own to provide the pure-file updates such as file renames, submodule updates, execute bit, etc.

[dandavison]

Thanks @mrjoel, I need to think about this proposal more but just wanted to mention that I am personally a

    file-style = omit
    hunk-header-style = file line-number syntax

user and so I definitely agree that there are some things that need fixing as you describe.

[dandavison]

@mrjoel How far off would we be if we simply changed file-style = omit to mean

Omit the file change line in the common case of a modified file, but retain it in all other cases, including e.g. new files, removed files, submodules, etc.

Personally, I think this is what I want when I use file-style=omit.

? I've pushed a branch that is intended to make that change https://github.com/dandavison/delta/pull/855

[mrjoel]

I'll think a bit more, but at first blush it seems to make it plenty workable for me. Perhaps be explicit in the definition that it omits the file change line if and only if there are one or more hunk header lines which are omitted for the noted file?

On the other hand, my proposed definition update would seem to cover my first group of examples, but not the second one which have a hunk header (exactly one each), for which the add/remove option is inferable but not explicit.

The main difference I think ends up being that your definition still results in not a file and hunk line for adds and removes, which likely is plenty workable. My only consideration to think more on offhand is interaction with navigation, where two navigation search hits will/may be present for adds and removes instead of always one per change.

I'll try to build and test that branch today.