Add sticky diff/hunk header in patch panel when scrolling multi-file/multi-hunk diffs

[rgoya]

Is your feature request related to a problem? Please describe.

When viewing a commit's full diff (or a file's diff with several hunks) in the patch panel, scrolling down causes the diff --git/---/+++/@@ ... @@ header lines to scroll out of view. For large diffs it becomes easy to lose track of which file or which hunk the currently visible lines belong to.

Describe the solution you'd like

When scrolling the main/patch panel, keep the most recent file header (--- a/..., +++ b/...) and hunk header (@@ -x,y +a,b @@ ...) pinned to the top of the view once it would otherwise scroll off-screen, similar the context.vim plugin's g:context_enabled behavior in vim (see this example, but only for file/hunk information, not all code!)

Ideally this would be visually distinguished (e.g. a different background or an underline) so it's clear it's a pinned header and not part of the normal scroll content (see context.vim URL above)

Describe alternatives you've considered

• Selecting each file individually in the commit's file panel keeps the filename visible on the side, but doesn't solve it for multi-hunk single-file diffs, and requires re-selecting per file rather than continuous scrolling.
• Tried using delta as a custom formatter for clearer header formatting. It improved readability of individual headers, but didn't solve the underlying issue. It seems since lazygit captures pager output as static text and scrolls it itself, so the header still scrolls out of view the same way it does with the built-in diff view.

Additional context

This would be most useful in the commit view's patch/file-diff panel, but would likely apply anywhere a git diff is rendered in the main panel (staging view, diffing mode, etc

[stefanhaller]

This is an interesting idea. I think it's a lot less important when using a pager such as delta (or diff-so-fancy), since these tend to repeat the current file for every diff hunk, so there it's only an issue for very long hunks (or when setting the context size to a large value). Could still be useful though.

As for feasibility: on master it's not possible to do except for the raw git diff; for pager output we don't know where files start. But the work that is prototyped here will make it easily possible. It's also a good fit for the file menu that's added in that prototype (pressing f opens a menu with all the files in the diff and lets you jump to them); the sticky header could act as a dropdown that opens this menu when clicked.

UI design: I'm hesitant to add this to the main view content because we might not match the visual design of the pager (unless we clearly separate it from the content with a divider line). Also, we'd be wasting two lines of the diff space. I'm leaning towards adding it to the tab title instead (just the new file name, not the full --- a//+++ b/ information or hunk headers).

[rgoya]

This is an interesting idea.

Thanks for considering it!

I think it's a lot less important when using a pager such as delta (or diff-so-fancy), since these tend to repeat the current file for every diff hunk, so there it's only an issue for very long hunks (or when setting the context size to a large value). Could still be useful though.

Agreed, mostly useful for raw git diff and or large hunks.

As for feasibility: on master it's not possible to do except for the raw git diff; for pager output we don't know where files start. But the work that is prototyped here will make it easily possible. It's also a good fit for the file menu that's added in that prototype (pressing f opens a menu with all the files in the diff and lets you jump to them); the sticky header could act as a dropdown that opens this menu when clicked.

Raw git diff is definitely the most straightforward to implement. I've just started playing with delta, so I'm not sure how flexible can the output be; but as of now it seems that it uses specific glyphs to delineate blocks (Δ for files, • for hunks):

Δ path/to/file.py

─────────────────────────────────────────────┐
• path/to/file.py:14: def foo(               │
─────────────────────────────────────────────┴────
...
─────────────────────────────────────────────┐
• path/to/file.py:24: def bar(               │
─────────────────────────────────────────────┴────

which could (?) be use to scan lines going off the screen during scrolling to pick what to show.

UI design: I'm hesitant to add this to the main view content because we might not match the visual design of the pager (unless we clearly separate it from the content with a divider line). Also, we'd be wasting two lines of the diff space. I'm leaning towards adding it to the tab title instead (just the new file name, not the full --- a//+++ b/ information or hunk headers).

Right. Screen real estate is precious! Having it in the title window could be enough:

╭─[0]─Patch────────────────────────────────────────
│
│ Δ path/to/file.py
│
│─────────────────────────────────────────────┐
│ • path/to/file.py:14: def foo(              │
│─────────────────────────────────────────────┴────
│ <diff>

scroll down eventually reads Δ:

╭─[0]─Patch─| path/to/file.py | ──────────────────
│
│─────────────────────────────────────────────┐
│ • path/to/file.py:14: def foo(              │
│─────────────────────────────────────────────┴────
│ <diff>
│ <diff>
| <diff>

scroll down eventually reads •:

╭─[0]─Patch─| path/to/file.py:14 def foo( |────────
│ <diff>
│
│─────────────────────────────────────────────┐
│ • path/to/file.py:14: def foo(              │
│─────────────────────────────────────────────┴────
│ <diff>

[stefanhaller]

Don't worry about the implementation, this is taken care of by the OSC-1717 mechanism invented in #5732. We don't need to parse delta's output.

I don't think I would include hunk headers at all here, I'd restrict this only to file headers. Hunk headers can get very long; your def foo( example is short, but in other languages or code bases they can get very long. A real-world, not uncommon example from this code base is pkg/commands/git_commands/submodule.go: func NewSubmoduleCommands(gitCommon *GitCommon) *SubmoduleCommands {; this is too long to show in the window title.

Also, file paths themselves could get long, and if we show only those, we have the option to truncate them in the middle rather than at the end so that you can see the most important information. This would be a lot trickier if we also include hunk headers.