mirror of
https://codeberg.org/dnkl/foot.git
synced 2026-02-10 04:27:45 -05:00
Allow any theme to be dark or light, determine it automatically
By definition, "[colors]" is a dark theme and the alternate theme
("[colors2]") is light.
A user who doesn't know about this definition (or about "[colors2]"),
might configure "[colors]" to be a light theme.
This is a reasonable mistake because
a. "colors" is an innocuous name
b. users who failed to run
"git merge-file ~/.config/foot/foot.ini $old_foot/foot.ini $new_foot/foot.ini"
after upgrading foot might not have "colors2" in their config.
The wrongly reported color theme (CSI 997) causes issues when apps
use it for selecting colors. I don't know if any relevant app does,
but learning this cost me some time, and maybe it's a good idea to
address this, even though it's technically a user error.
Solution 1:
Stop responding to CSI 996.
The Contour spec is [ambiguous](https://github.com/contour-terminal/contour/issues/1659#issuecomment-3596983337).
Apps might want to prefer the more widely available OSC 10/11 for detecting dark/light mode.
I think Vim does; and at least NeoVim still uses the Contour protocol to subscribe to notifications.
We'd still send DSR 2031 notifications, however that would work just fine for apps like NeoVim that ignore the payload and only use it as trigger to query for the theme again via OSC 10/11.
(Since we can only switch between two themes, we wouldn't even waste bandwidth.)
Solution 2:
Assuming the themes are only meant for the dark/light mode toggle,
rename them to "colors-dark" and "colors-light",
and maybe report color theme only for those
(and not when the user has the legacy "colors" and "colors2").
Solution 3 (implemented here):
Assuming the themes are intended to be used for things other than
dark/light toggle,
- have foot automatically detect whether the current theme is dark or light
- if needed, allow users to override this (e.g. "colors.is_dark = true")
I guess I have a slight preference for solution 2 because it seems
relatively simple. But I don't know what's the goal.
Apparently switching to dark/light mode at dusk/dawn is a feature
of macOS and there are solutions like darkmon for other OSes, so I
guess dynamic switching is a useful feature in principle.
This commit is contained in:
parent
7e2ea901d6
commit
4a2e5df554
10 changed files with 50 additions and 31 deletions
|
|
@ -664,9 +664,7 @@ manipulation sequences. The generic format is:
|
|||
: Query the current (color) theme mode
|
||||
: contour
|
||||
: The current color theme mode (light or dark) is reported as *CSI ?
|
||||
997 ; 1|2 n*, where *1* means dark and *2* light. By convention, the
|
||||
primary theme in foot is considered dark, and the alternative theme
|
||||
light.
|
||||
997 ; 1|2 n*, where *1* means dark and *2* light.
|
||||
|
||||
|
||||
# OSC
|
||||
|
|
|
|||
|
|
@ -1138,17 +1138,12 @@ dark theme (since the default theme is dark).
|
|||
# SECTION: colors2
|
||||
|
||||
This section defines an alternative color theme. It has the exact same
|
||||
keys as the *colors* section. The default values are the same, except
|
||||
for *dim-blend-towards*, which defaults to *white* instead.
|
||||
keys and default values as the *colors* section.
|
||||
|
||||
Note that values are not inherited. That is, if you set a value in
|
||||
*colors*, but not in *colors2*, the value from *colors* is not
|
||||
inherited by *colors2*.
|
||||
|
||||
In the context of private mode 2031 (Dark and Light Mode detection),
|
||||
the alternative theme (i.e. the *colors2* section) is considered to be
|
||||
the light theme (since the default, the primary theme, is dark).
|
||||
|
||||
# SECTION: csd
|
||||
|
||||
This section controls the look of the _CSDs_ (Client Side
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue