Config file and custom themes similar to bat

[dandavison]

Config file and custom themes similar to bat

[dandavison]

@jamescostian Thank you! Done: #84

[dandavison]

Hi, thanks for the feedback!

Regarding a config file, delta is nearly always used in conjunction with git, so the ~/.gitconfig file plays the role of bat's config file. I.e. both files specify the desired command-line invocation. Would you agree that we don't need an additional config file beyond entering the command-line invocation in ~/.gitconfig?

For custom themes, could you expand on what you'd like delta to add? Currently we have the themes below available. In order to add a new theme, the process is actually to clone bat and add the theme in the bat repo following the bat instructions! Then, copy the assets/themes.bin from the bat repo to the delta repo. This is referenced here but perhaps I could spell it out a bit more.

$ delta --list-themes 
Light themes:
    GitHub
    Monokai Extended Light
    OneHalfLight
    ansi-light
Dark themes:
    1337
    DarkNeon
    Monokai Extended
    Monokai Extended Bright
    Monokai Extended Origin
    OneHalfDark
    Sublime Snazzy
    TwoDark
    ansi-dark
    base16
    zenburn

[clarfonthey]

Certainly! I accidentally pressed enter when composing this and submitted it prematulrely.

In terms of config… you're right that gitconfig takes that role, and I think we'd be fine without a separate config file. It is nice that bat offers a bit more control and allows a config file which lets you specify command-line options ahead of time, and being able to do that might be a bit more user-friendly than gitconfig.

In terms of custom themes, the main issue is having to recompile the binary every time. It'd be nice if they could be loaded dynamically from e.g. ~/.config somewhere. Honestly, if we're going to just pull from bat's config, I'd be fine with just using ~/.config/bat/themes.

[mgred]

@dandavison

In order to add a new theme, the process is actually to clone bat and add the theme in the bat repo following the bat instructions! Then, copy the assets/themes.bin from the bat repo to the delta repo.

I added Nord.mtTheme to a local bat repo and recreated the themes. I can now choose this from the default themes in bat as expected. Unfourtunatly, when I copy the generated file assets/themes.bin to a delta repo's assets folder and reinstall it with cargo install --force git-delta the Theme is not recognized 😕
What am I do wrong?

BTW: I think one does not need to clone bat to add a custom theme. It should be sufficient to add a theme to ~/.config/bat/themes and call bat cache --build then copy the generated files themes.bin and syntaxes.bin from ~/.cache/bat

[dandavison]

@mgred You need to recompile locally (e.g. cargo build --release) to include the new themes in the executable. The new executable will then be at target/release/delta in the git repo. Note that if you've been using cargo install, you will now probably have two different delta executables on your system (for me on MacOS, cargo install installs into ~/.cargo/bin/).

I believe that cargo install git-delta is just pulling the released version from the public crates.io package registry, so the themes there won't differ from what you had already. Of course, you can open a PR against delta to update the themes.bin file to add a new theme, and then we could make a new release with it.

I expect this process could be made slicker, perhaps by continuing to copy exactly what bat does, using ~/.config etc. But for now, the themes/languages that delta offers are those that it was compiled with, so someone wishing to add to them needs to recompile delta.

[dandavison]

I've updated the README to make this a bit clearer, but I think @clarfon is right:

In terms of custom themes, the main issue is having to recompile the binary every time. It'd be nice if they could be loaded dynamically from e.g. ~/.config somewhere. Honestly, if we're going to just pull from bat's config, I'd be fine with just using ~/.config/bat/themes.

I'd also be happy for delta to read from ~/.cache/bat, and thus to rely entirely on the bat workflow for adding new themes/languages. This shouldn't be a difficult change; delta is already copying code under license from bat for assets management; it probably just needs to copy a bit more :)

[dandavison]

It is nice that bat offers a bit more control and allows a config file which lets you specify command-line options ahead of time, and being able to do that might be a bit more user-friendly than gitconfig.

@clarfon I'm not quite seeing the distinction here. We can enter command-line options ahead of time in ~/.gitconfig. Also, it supports comments so you can try out various different combinations and keep all but one commented out. E.g. my ~/.gitconfig currently looks like

[core]
    ...
    pager = delta --light --max-line-distance=0.6
    # pager = delta --dark --plus-color="#002800" --plus-emph-color="#0E7C0E"
    # pager = diff-so-fancy | less -R

...

bat's config file would literally just be another list of command line arguments. If we supported both, it would be pretty confusing, because people would be in doubt which had precedence, right?

[dandavison]

So to be explicit, I agree with @clarfon and propose leaving this issue open to have delta use bat's themes and languages workflow including dynamic loading at runtime.

[mgred]

@mgred You need to recompile locally (e.g. cargo build --release) to include the new themes in the executable. The new executable will then be at target/release/delta in the git repo. Note that if you've been using cargo install, you will now probably have two different delta executables on your system (for me on MacOS, cargo install installs into ~/.cargo/bin/).

Thanks @dandavison! That was doing the trick. I can no use the Theme as expected 🙏

I believe that cargo install git-delta is just pulling the released version from the public crates.io package registry, so that won't differ from what you had already. Of course, you can open a PR against delta to update the themes.bin file to add a new theme, and then we could make a new release with it.

Sounds great 👍 I would then also consider doing the same for bat 😎

Thanks for your help and explanation.

[dandavison]

Closed by #76.

The suggestion of a config file has not been implemented. One argument for a config file is that delta can be used with standard unified diff output, in which case the git (or mercurial) config files will not be consulted. This use case could however be addressed by a shell alias setting the desired delta options. Since most usage is with git, I think it makes sense not to introduce a second config file but rather to continue to use the git config file as delta's config file.

[jamescostian]

The README still says

Delta does not currently support reading these files dynamically from ~/.config as bat does, but this is a feature that could be added

Could that be updated?

[Nemo157]

Given that you need to specify delta in two places in the .gitconfig, it'd be nice to have a config file to not have to repeat the customization twice

[core]
    pager = delta --theme ansi-light --plus-color=white --minus-color=white --plus-emph-color=white --minus-emph-color=white --commit-style=plain --file-style=box --hunk-style=plain --keep-plus-minus-markers

[interactive]
    diffFilter = delta --color-only --theme ansi-light --plus-color=white --minus-color=white --plus-emph-color=white --minus-emph-color=white

[dandavison]

@Nemo157 good point.

Just throwing out another possibility: for people who are happy creating shell scripts and staying on top of their $PATH, you could create an executable shell script in a location on your $PATH (so for me I would put the shell script at ~/bin/delta), and place the delta command line in there, something like

#!/bin/bash
exec delta --commit-style box --commit-color="red" --theme 'GitHub' "$@"

Then, ~/.gitconfig can be clean:

[core]
    pager = delta

[interactive]
    diffFilter = delta --color-only

I'm not ruling it out but the downside with a config file is that then we have to have rules regarding the precedence of the config file, the ~/.gitconfig, and any relevant env vars.

[Nemo157]

@dandavison that sounds like a great workaround, thanks!

[lilyball]

I would really like to see delta add support for a config file anyway. The problem with adding my own script is I now need to add another entry to my PATH, as delta is currently installed in the very first entry I have in my PATH. I don't want to modify my PATH just to intercept delta.

While I am a fan of reading delta config from gitconfig, I do recognize that this doesn't make sense when piping output to delta directly, but I think having a ~/.config/delta/config file that works similarly to ~/.config/bat/config would be really helpful.

Edit: Ok I just realized I can of course set git config to look at an absolute path instead of relying on PATH for lookup. But that makes my config less flexible as now I have to ensure the script exists at that path on all machines that I copy my config to.

[lilyball]

FWIW another issue with "wrap delta with your own script" is delta doesn't like it when you pass flags multiple times, so e.g. if my script provides --theme base16 and I try to give it e.g. --theme ansi-dark I get an error.

[dandavison]

@lilyball I 100% agree. I was planning on coming back to this ticket and saying thanks to @clarfon for originally raising this and that I think you're right that Delta needs a better config file solution.

The good news is that the next release of delta (coming soon, next week I hope) is going to fully support a lot of new configuration possibilities via a [delta] section in git config. I'll post more details here shortly.