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.
* Recognize 'CSI ? 996 n', and respond with
- 'CSI ? 997 ; 1 n' if the primary theme is active
- 'CSI ? 997 ; 2 n' if the alternative theme is actice
* Implement private mode 2031, where changing the color
theme (currently only possible via key bindings) causes the terminal
to send the same CSI sequences as above.
In this context, foot's primary theme is considered dark, and the
alternative theme light (since the default theme is dark).
Closes#2025
* The toplevel icon is now set to the app-id, unless "overridden" by
OSC-1 or OSC-0.
* Implemented OSC-1
* OSC-0 extended to also set the icon
* Implemented CSI 20 t - report window icon
* Implemented CSI 21 t - report window title
* Implemented CSI 22 ; 1 t - push window icon
* Implemented CS 23 ; 1 t - pop window icon
* Extended CSI 22/23 ; 0 t to also push/pop the icon
* Verify app-id set by OSC-176 is valid UTF-8
* Verify icon set by OSC-0/1 is valid UTF-8
This patch adds support for window focusing, and sending events back
to the client application when a notification is closed.
* Refactor notification related configuration options:
- add desktop-notifications sub-section
- deprecate 'notify' in favor of 'desktop-notifications.command'
- deprecate 'notify-focus-inhibit' in favor of
'desktop-notifications.inhibit-when-focused'
* Refactor: rename 'struct kitty_notification' to 'struct
notification'
* Pass a 'struct notification' to notify_notify(), instead of many
arguments.
* notify_notify() now registers a reaper callback. When the notifier
process has terminated, the notification is considered closed, and we
either try to focus (activate) the window, or send an event to the
client application, depending on the notification setting.
* For the window activation, we need an XDG activation token. For now,
assume *everything* written on stdout is part of the token.
* Refactor: remove much of the warnings from OSC-99; we don't
typically log anything when an OSC/CSI has invalid values.
* Add icon support to OSC-99. This isn't part of the upstream
spec. Foot's implementation:
- uses the 'I' parameter
- the value is expected to be a symbolic icon name
- a quick check for absolute paths is done, and such icon requests
are ignored.
* Added ${icon} to the 'desktop-notifications.command' template. Uses
the icon specified in the notification, or ${app-id} if not set.
This implements
https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3704bd83,
in-band window resize notifications.
When user enables private mode 2048 (in-band resize
notifications), *always* send current size, even if the mode is
already active.
This ensures applications can rely on getting a reply from the
terminal.
This adds support for a new OSC escape sequence: OSC 176, that lets
terminal programs tell the terminal the name of the app that is
running. foot then sets the app ID of the toplevel to that ID,
which lets the compositor know which app is running, and typically
sets the appropriate icon, window grouping, ...
See: https://gist.github.com/delthas/d451e2cc1573bb2364839849c7117239
This implements private mode 2027 - grapheme cluster processing, as
defined in the "Terminal Unicode Core"[1] specification.
Internally, we just flip the already existing option "grapheme
shaping". Since it's now runtime changeable, we need a copy of it in
the terminal struct, rather than referencing the conf object.
[1]: 13fc5a8993/spec/terminal-unicode-core.tex (L50-L53)
This patch adds support for the OSC-133;A sequence, introduced by
FinalTerm and implemented by iTerm2, Kitty and more. See
https://iterm2.com/documentation-one-page.html#documentation-escape-codes.html.
The shell emits the OSC just before printing the prompt. This lets the
terminal know where, in the scrollback, there are prompts.
We implement this using a simple boolean in the row struct ("this row
has a prompt"). The prompt marker must be reflowed along with the text
on window resizes.
In an ideal world, erasing, or overwriting the cell where the OSC was
emitted, would remove the prompt mark. Since we don't store this
information in the cell struct, we can't do that. The best we can do
is reset it in erase_line(). This works well enough in the "normal"
screen, when used with a "normal" shell. It doesn't really work in
fullscreen apps, on the alt screen. But that doesn't matter since we
don't support jumping between prompts on the alt screen anyway.
To be able to jump between prompts, two new key bindings have been
added: prompt-prev and prompt-next, bound to ctrl+shift+z and
ctrl+shift+x respectively.
prompt-prev will jump to the previous, not currently visible, prompt,
by moving the viewport, ensuring the prompt is at the top of the
screen.
prompt-next jumps to the next prompt, visible or not. Again, by moving
the viewport to ensure the prompt is at the top of the screen. If
we're at the bottom of the scrollback, the viewport is instead moved
as far down as possible.
Closes#30
This patch adds support for DECRQSS (request Selection or Setting),
for the following sub-queries:
* DECSTBM Set Top and Bottom Margins
* SGR Set Graphic Rendition
* DECSCUSR Set Cursor Style
Closes#798
Using underlining for parameters allows the angle brackets to be
removed while still keeping a visual separation between literals
and parameters. The removes any uncertainty about whether the
angle brackets are part of the sequence or not. It also mirrors
the formatting used further down in the document.
There's no mention of SS0 or SS1 functions in ECMA-48 or ECMA-35.
0x0E/0x0F are SO/SI (Shift In/Out) in "7-bit environments" or LS0/LS1
(Locking Shift 0/1) in "8-bit environments". The former is the one
that applies to foot, since it generally follows "7-bit" conventions
due to its use of UTF-8.
See also: ECMA-35 §7.2 and §9.2.
In a recent Debian build from master, Lintian complained about a bad
whatis entry for this manual page. The tag description [1] says a NAME
section is required. It is added here.
[1] https://lintian.debian.org/tags/bad-whatis-entry.html
