Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Allow color theme overrides on the command line #1745

Closed
zachriggle opened this issue Jul 21, 2021 · 3 comments
Closed

Feature: Allow color theme overrides on the command line #1745

zachriggle opened this issue Jul 21, 2021 · 3 comments
Labels
duplicate This issue or pull request already exists feature-request New feature or request

Comments

@zachriggle
Copy link

zachriggle commented Jul 21, 2021

Thanks!

Thanks again for making such a useful tool, @sharkdp. Please consider adding a "Donate" button / pill to your README.md so I can toss you some beer money.

TL;DR

I want to be able to override the "highlight" color via a flag, but while we're at it, it seems it might be useful for other projects that build on bat to be able to change colors of arbitrary things.

(I've worked around this locally, for the time being, by creating a copy of the .tmTheme I'm interested in, renaming it, making the modifications I want, and re-creating the cache. This is how I ran across #1726.)

Feature Request

One of the cooler tools that I've seen built on top of bat is git-delta, which is also a Rust project, and manually overrides some of the theme color elements in order to show added lines as green, and removed lines as red (depending on options).

For example, it would be nice to be able to specify e.g.

$ bat --theme-override default.lineHighlight=#002800
# or
$ bat --theme-override lineHighlight=#002800

As an example for WHY this is needed, Solarized Dark's default highlight color is #073642, but it shows up as #1ED1FF (bright blue) in iTerm2 using the official Solarized Dark theme at the same time.

It would be nice to be able to easily override these settings, without modifying the underlying theme and recompiling all of the assets.

Stretch Goals, Risks and Complications

This might be more complicated than face value, the above setting is actually at the PLIST path settings[0].settings.lineHighlight, and the enclosing dictionary for default settings has no name or scope entry (i.e., it is describing the default settings, which is why I chose to use default.lineHighlight in my example above).

Changing the highlight color of other settings (e.g. the color of a quoted string) may be more difficult, since they have different names and scopes. Consider trying to change the color of strings -- there are multiple settings

  • name: String, scope: string
  • name: StringNumber, scope: string
  • name: Regexp, scope: string.regexp
  • name: Quoted String, scope: string.quoted.double, string.quoted.single
    and so on...

Overall, Solarized Dark has 179 different named color settings / scopes / etc.

Providing command-line access to these might look something like this, which only overrides the settings with scope=="string" (and not string.regexp) and defaults to overriding the foreground setting.

$ bat --theme-override string.foreground=#00ff00

While overriding all scopes that match an (optional) suffix might look like:

$ bat --theme-override string.*.foreground=#00ff00

Which would match string, string.regexp, string.quoted.double, string.quoted.single, and any other string.xxx scope's foreground color.

With this in place, it should be possible to override other settings (or create non-existent ones). Consider setting the default background color, and the background color just for strings. It might look like:

$ bat --theme-override background=#00ff00
$ bat --theme-override string.*.background=#00ff00

Caveats

The mechanism I suggest for wildcards, using an asterisk (*) will probably cause most shells to try to use globbing, and thus require single-quoting. This is a footgun. Some shells will leave the star in-place when it fails to glob correctly (e.g. bash) but others will throw an error (e.g. zsh).

$ bash -c 'echo foo*bar'
foo*bar

$ zsh -c 'echo foo*bar'
zsh:1: no matches found: foo*bar

It might be better to use an operator like % instead of *, but I don't want to go back and edit this whole thing again for fear of not being consistent.

Closing

Ultimately the parsing and scoping etc. process are probably cumbersome (and I expect this is why you ship pre-compiled .bin files).

Hopefully, at least for the the top-level, default colors this is achievable.

@keith-hall
Copy link
Collaborator

Thanks for the feedback. There's some existing discussion regarding this here:
#339

Changing the highlight color of other settings (e.g. the color of a quoted string) may be more difficult, since they have different names and scopes. Consider trying to change the color of strings -- there are multiple settings

* name: `String`, scope: `string`

* name: `StringNumber`, scope: `string`

* name: `Regexp`, scope: `string.regexp`

* name: `Quoted String`, scope: `string.quoted.double, string.quoted.single`
  and so on...

I would personally ignore the name key completely - most color schemes don't have them, they can be duplicated etc. I think it's better to go purely with scope selectors, even though it is more technical.

While overriding all scopes that match an (optional) suffix might look like:

$ bat --theme-override string.*.foreground=#00ff00

I would vote for separating the scope from the "color context" being changed, for simplicity and clarity. i.e. $ bat --theme-override string foreground=#00ff00,background=#ffffff,font_style=italic where string is the scope (no need for wildcards because it matches with scope selectors and would thus match string.unquoted etc - though we'd need to define precedence still so that if you really only want to update the existing string rule, it would do so, while if you wanted to also update all matching rules, it could do that too...)

@Enselic
Copy link
Collaborator

Enselic commented Aug 4, 2021

Thanks for a good feature request. Let's close this as a

Duplicate of #339

though and keep discussion in one place.

@Enselic
Copy link
Collaborator

Enselic commented Aug 4, 2021

Duplicate of #339

@Enselic Enselic marked this as a duplicate of #339 Aug 4, 2021
@sharkdp sharkdp added the duplicate This issue or pull request already exists label Aug 7, 2021
@sharkdp sharkdp closed this as completed Aug 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants