Add --gitsigns option (#3404)

[flashios09]

See #3404

[flashios09]

@sand4rt take a look and tell me what you think :)

[Enselic]

Hi! What is the problem with the default signs? If they are problematic somehow it's probably better to fix the problems they have than to add complexity to the code and for users.

[flashios09]

than to add complexity to the code and for users

Hi @Enselic ,
Which complexity are you talking about ?

This PR will just add --gitsigns option, just like the --style option, used to customize user preferences.

This is how gitsigns looks with the modern preset(bat --gitsigns=modern path/to/file):

The whole feature is about 100 lines, 90% of those +1000 lines are just tests :)

[Enselic]

Ok, let's start with the first question.

What is the problem with the default signs?

[sand4rt]

Ok, let's start with the first question.

What is the problem with the default signs?

They are not the same as other terminal apps like gitsigns.nvim

[Enselic]

Why not make gitsigns configurable instead of bat?

[sand4rt]

Why not make gitsigns configurable instead of bat?

It is configurable in gitsigns, but i find the line-based indicators much clearer and easier to parse visually. In my opinion they reduce visual noise compared to the current symbols, and make diffs easier to scan. Popular editors like VSCode and JetBrains IDEs also use line markers as the default.

[flashios09]

Ok, let's start with the first question.

What is the problem with the default signs?

Hi @Enselic , what is the problem with the default cat binary that comes with almost all UNIX based systems ?
The answer is OUTDATED, that's why we have bat, rg instead of grep, fd instead of find, eza instead of ls ...

What it the problem with the default signs ?

OUTDATED, we aren't in 2015 anymore when SublimeText2 was the most popular text editor(all the respect for SublimeText, still one of the best text editors), at that time, the default gitsigns was:

• ~ in orange for modified lines
• + in green for new(added) lines
• - in red for deleted lines

Those aren't the "default" anymore, with the new era of text editors/IDE, VSCode and all its fork(Cursor ...), Intellij IDE, Neovim with gitsigns.nvim plugin, all are using new gitsigns:

• | in blue for modified lines
• | in green for new(added) lines
• - in red for deleted lines

With this PR, we will be able to:

1. Use the TextMate theme file to apply the colors to gitsigns(if the scope exists, otherwise use the current default colors), like this we can change/customize the modified/added/deleted sign colors
2. Use the --gitsigns option to customize the signs, via the classic/modern preset or a custom 4 comma-separated characters(already mentioned/explained in the help command).

BEFORE(classic gitsigns):

AFTER(modern gitsigns):

Now tell me, which one is easier to get the git changes from ? classic preset or the modern one used by all modern text editors/IDE ?

PS:
This PR has 0 breaking changes, no effect at all on the default bat command with all the already existent options/config, classic(the current one) is still the default preset for gitsigns, which means only the user who wants to customize gitsigns, will need to use the new --gitsigns option or the BAT_GITSIGNS env var, just like the --style or --theme options.

[Enselic]

Sorry for being annoying. I just needed to be convinced this was a worthwhile thing to change, and now you have convinced me. Thank you for taking the time to do so.

I (or some other maintainer) will look at the details later when I get the time.

[keith-hall]

Scope selectors from the theme generally shouldn't be expected to exactly match a scope, but instead use scope selector matching logic to determine which theme rules match and which has the highest precedence... Probably it doesn't matter too much here, but I would prefer consistency with how highlighting works

[flashios09]

Sorry I didn't get the point here ?
TextMate theme files usually use markup.inserted, markup.changed and markup.deleted scopes to define colors for gitsigns:

[keith-hall]

It seems like I missed this reply earlier, sorry about that. I meant that the tmTheme may choose to have rules with less specific scope selectors like markup which would match markup.deleted, markup.changed etc. or even multiple rules could theoretically match, and whose styles would get applied/merged together etc. based on precedence order. So my idea was to use proper scope selector logic instead of checking for string equality, but probably it isn't going to be necessary in practice, because, like you pointed out, most themes have these specific rules.

[flashios09]

but probably it isn't going to be necessary in practice, because, like you pointed out, most themes have these specific rules

Sorry for late response, do you want/suggest using ScopeSelector::does_match instead because i got confused here ?

[keith-hall]

I would prefer it, yes please 👍

[keith-hall]

it would be great if we could also update the auto completion scripts please, so they would suggest the new argument and it's possible values

[flashios09]

Sorry i didn't get the point here, can you explain more please ? What do you mean by "update the auto completion scripts" ?

[keith-hall]

There are some scripts which are used for completions in various shells like bash, fish, zsh. When typing bat --t and pressing the tab key, it will automatically finish writing --theme for example. So when adding new command line options like --gitsigns, it would be nice to ensure the completion scripts know to offer that as a suggestion. If it's too much hassle, don't worry, we can always do it later. I think I got Copilot or another LLM AI to help me last time I needed to do it because I don't know all the various shell syntaxes.