Fixed / pinned file name / function / chunk header

[dandavison]

Fixed / pinned file name / function / chunk header

[dandavison]

The architecture is simpler (more unidirectional) than that: git's stdout is piped to delta's stdin, and delta's stdout is piped to $PAGER.

It's delta that spawns a child $PAGER process; configuring delta as git's core.pager is very similar to doing git --color=always some_git_command | delta.

[dandavison]

This is really interesting. I haven't had any ideas though beyond what's been suggested already: we need some sort of new pager, or work done on an existing pager, to allow it to display configurable fixed lines. Maybe you can pass it a collection of regular expressions, each one identifying a new fixed line, and the fixed input for fixed line i updates each time a new line is encountered matching regexp i. So, like in sharkdp/bat#754, the conclusion seems to be that it can't be done via changes in this repo (since both delta and bat spawn a (configurable) child process to handle paging).

I'd definitely be happy for there to be further discussion here about how it could relate to delta, even if this ticket is closed. And if there is discussion/progress elsewhere on this idea, please someone link this ticket.

[fdcds]

Going via nushell seems to be the most promising approach. That would basically make delta's output:

• a table with rows of files and one column, its fields each containing:
  • a table with rows of chunks and one column, its fields each containing:
    • a table with rows for lines and 3 columns:
      • the line number
      • added/+, removed/-, replaced / !
      • the change for this line

With some variant of nushell/nushell#389 the contents of the "parent fields" could be pinned to the top of the screen, as proposed here.

[dandavison]

That would basically make delta's output...

Is it fair to say that that's a description of how git output could be presented in nushell rather than delta specifically?

[devurandom]

As I understand nushell, to make use of its enhanced output and browsing capabilities, there would have to be a plugin that outputs a certain kind of JSON-RPC. This plugin could probably be implemented by leveraging delta's code as a library, but instead of piping the prettified diff back through git into the $PAGER, it would ... display it in some other way.

If I understand delta's role and architecture correctly [1], then the middle layer between delta and the terminal emulator, i.e. git, would have to also be replaced with a nushell plugin, in order to be able to transport the data and integrate the different outputs in a usable way. This seems pretty involved, but on the other hand the cleanest solution that came to my mind so far.

[1]: git opens two pipes to/from delta's stdin/stdout, sends diff -u-compatible lines in, and receives delta's pretty output. It then opens a pipe to $PAGER and connects $PAGER's stdout to the terminal. When it sends the merged output of (log) messages and pretty diff through the pipe, $PAGER renders things in a way the terminal emulator understands and writes it to stdout, i.e. into the terminal. Is that correct? Did I miss something?

[devurandom]

In that case, maybe delta could "just" produce nushell compatible output (or there could be a nushell_plugin_delta) and nushell would just display it nicely.

[dandavison]

Or perhaps for better composability, someone writes a component that converts git output to a nushell-compatible input format, and this new component can be inserted between delta and nushell for delta users and between git and nushell for non-delta users? I.e. the problem of displaying git output in nushell would be orthogonal to delta; but delta can be inserted into the pipeline to add colors.

Ref nushell/nushell#602

[dandavison]

delta's test suite includes a test that guarantees that delta's output is (with delta-specific structural changes such as separator lines disabled and ansi color codes stripped) byte-for-byte identical to the input it receives from git. So, I believe this means that delta could be inserted or not into a pipeline something like:

git |         git_nushell_adapter | nushell
git | delta | git_nushell_adapter | nushell

The requirement would be that nushell can handle delta's ansi color codes, but presumably it would already be handling color codes coming from git. If this is right, then the remaining work (getting git output into nushell) is orthogonal to delta.

[dandavison]

...almost! There's the + / - beginning-of-line markers, which delta strips from the git input. So perhaps delta should have an option to leave them in place.

[devurandom]

I would go the other way and rather integrate delta's diff-printer into such "git_nushell_adapter".

But you are right, maybe there is nothing left to be done on delta's end and it just needs someone to implement a "sticky fields" feature of nushell and that "git_nushell_adapter". Shall we close this ticket?

[dandavison]

I would go the other way and rather integrate delta's diff-printer into such "git_nushell_adapter".

Does it worry you with that approach that delta development would then be forked: every new delta feature (or bug fix) would have to be implemented twice, in two different code bases?

Also it seems that it might complicate the development of the git_nushell_adapter (which is already a fairly complex undertaking) to have to also think about syntax highlighting and within-line edit inference algorithms.

[devurandom]

I try to think of programs (CLI or distributed services, does not matter) as pipelines (not to be confused with Unix pipes) with one or more sources, transformation steps and one or more outputs. From experience, I learnt that it is good to put transformations first that structure the data and possibly enrich it. User-facing presentation generally should go last. That allows the middle part of the pipeline to focus solely on the "business logic", while the beginning deals with input format and sources, while the presentation is only a concern of the code which knows the capabilities of the output device and the wishes of the user.

I would go the other way and rather integrate delta's diff-printer into such "git_nushell_adapter".

Does it worry you with that approach that delta development would then be forked: every new delta feature (or bug fix) would have to be implemented twice, in two different code bases?

That's why I suggested to make the different stages of the pipeline a library, so it can be reused.

Also it seems that it might complicate the development of the git_nushell_adapter (which is already a fairly complex undertaking) to have to also think about syntax highlighting and within-line edit inference algorithms.

Hm, probably there would be a "git wrapper for nushell", that outputs git data in a structured and nushell compatible way. And delta's diff rendering could be integrated into the nushell viewer.

[dandavison]

Thanks for the discussion @devurandom. I'll close this for now since there are no immediate delta development implications, but feel free to add any further thoughts.