-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Feature: Allow color theme overrides on the command line #1745
Description
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.