At first, an OSC-8 URI range was added when we received the closing
OSC-8 escape (i.e. with an empty URI).
But, this meant that cursor movements while the OSC-8 escape was in
effect wasn’t handled correctly, since we’d add a range that spanned
the cursor movements.
Attempts were made to handle this in the cursor movement functions, by
closing and re-opening the URI.
However, there are too many corner cases to make this a viable
approach. Scrolling is one such example, line-wrapping another.
This patch takes a different approach; emit, or update the URI range
when we print to the grid. This models the intended behavior much more
closely, where an active OSC-8 URI act like any other SGR attribute -
it is applied to all cells printed to, but otherwise have no effect.
To avoid killing performance, this is only done in the “generic”
printer. This means OSC-8 open/close calls must now “switch” the ASCII
printer.
Note that the “fast” printer still needs to *erase* pre-existing OSC-8
URIs.
Closes#816
If a mouse selection was ongoing, and the user switched
workspace (probably using the keyboard...), and then back, the
selection was still treated as ongoing, while all other mouse state
has been reset.
This meant the user had to tap at least once to stop the selection.
The parsing context keeps a pointer to the current section name. This
is used when logging errors.
However, the pointer was into a buffer allocated by getline(). This
buffer are often re-used in the next call to getline(), or free:d.
Regardless, the section name pointer is invalid after the next call to
getline(), which meant all error messages were logging a correct
section name.
The missing return caused us to fall through to the bottom of the
function, where we ended with an error message:
[main].letter-spacing: 0: not a valid option: letter-spacing
Closes#795
This adds a new meson option that controls whether the example theme
files should be installed or not. The default is true.
Previously, themes were gated by the -Ddocs option.
This allows you to configure custom colors to be used when colors are
being dimmed (`\E[2m`).
It is implemented by color matching (just like
bold-text-in-bright=palette-based); the color-to-be-dimmed is matched
against the current color palette.
If it matches one of the regular colors (colors 0-7), the
corresponding “dim” color will be used.
If it matches one of the bright colors (colors 8-15), the
corresponding “regular” color will be used (but *only* if the “dim”
color has been set).
Otherwise, the color is dimmed by reducing its luminance.
The default behavior, i.e. when dim0-7 hasn’t been configured, is to
dim by reducing luminance for *all* colors. I.e. we don’t do any color
matching at all. In particular, this means that dimming a bright color
will *not* result in the corresponding “regular” color.
Closes#776
Similar to modifyOtherKeys=1 (foot’s default, and only, mode), except
that:
* All modifiers (and not just Ctrl) generate \E[27;m;n~ escapes
* Regular keys (with modifiers) also generate \E[27;m;n~ escapes (for
example, C-h no longer generates ^H, but \E[27;5;104~)
For our keymap based lookups, this is handled by adding
MOD_MODIFY_OTHER_KEYS_STATE<N> variants.
For “generic” keys, we simply adjust the conditions for when to emit a
\E[27;m;n~ escape - the only requirement is that at least one modifier
is active.
If there aren’t any seats available, input is not possible (neither
keyboard nor mouse input).
Note that this is not the same thing as e.g. no keyboard being plugged
in. In this case, there will be a seat, but without the keybaord
capability. Input may not be possible _right now_, but may be later,
if the user plugs in a keyboard.
Closes#779
When we’re using CSDs, we’ve up until now rendered a 5px invisible
border. This border handles interactive resizing. I.e. hovering it
changes the mouse cursor, and mouse button events are used to start an
interactive resize.
This patch makes it possible to color part of (or the entire) border,
with a configurable color.
To facilitate this, two new options have been added:
* csd.border-width
* csd.border-color
border-width defaults to 0, resulting in the look we’re used to.
border-color defaults to the title bar color. If the title bar color
hasn’t been set, it defaults to the default foreground color (just
like the title bar color does).
This means that, setting border-width but not border-color, results in
a border that blends with the title bar.
The serial is used when copying/pasting data from the clipboard. Up
until now, we’ve used the serial from the keyboard/mouse enter
events.
This works in most cases, but breaks in the following example:
$ wl-copy WLCOPY
/* Ctrl+Shift+v works fine (pastes "WLCOPY") */
$ printf "\033]52;c;eHl6\a"
/* Ctrl+Shift+v pastes "WLCOPY" instead of "xyz" */
Shifting focus away and then back to the foot window, and re-executing
the printf works, suggesting the “enter” serial is no longer valid
after another process(?) has copied something to the clipboard.
Updating the serial on key press/release (and the corresponding mouse
serial on mouse button events) seems to fix this.
I’ve also tested that “normal” copy/paste operations, within the same
foot instance, and between foot and other applications, are still
working. In at least river (wlroots based), and GNOME/mutter.
Closes#753
This fixes an issue where pasting (using e.g. OSC-52) in client
applications that doesn’t do this conversion themselves, like tmux,
doesn’t work.
Closes#752
Grapheme shaping is now enabled by default in foot. However, when
generating the profiling data in PGO builds, this results in skewed
optimizations.
The end result is worse benchmark results regardless of whether
grapheme-shaping is enabled or not (when running the benchmarks).
This changes the default value of tweak.grapheme-shaping to “yes”,
thus enabling grapheme shaping by default.
It also changes the default value of tweak.grapheme-width-method to
“wcswidth”, for maximum compatibility with terminal applications.
foot doesn't show desktop notifications (via OSC777) if the current
terminal has keyboard focus.
This is probably a sane default, but there are use cases where showing
a notification regardless of the focus status may be desired. For
example, a completion notification of a long running task inside a
non-focused tmux window.
This PR adds the notify-focus-inhibit option which can be used to
disable inhibition of notifications when the window has focus.
The default value is `yes`, which retains the old behavior.
That locale may not exist. Instead, require the user/build script to
explicitly set an UTF-8 locale.
Document this in INSTALL.md, and in the bundled PKGBUILD.
Previously, soft-wrapped lines were not selected correctly, as the
selection logic was hardcoded to simply select everything between the
first and last column on the current terminal row.
Now, we scan backward and forward, looking for hard-wrapped
lines. This is similar to how word-based selection works.
Closes#726
With dpi-aware=auto (the default), scale fonts using DPI *only*
if *all* available monitors have a scaling factor of one.
The idea is this: if a user, with multiple monitors, have enabled
scaling on *at least* one monitor, he/she has most likely done so to
match the size of his/hers other monitors.
For example, if the user has one monitor with a scaling factor of one,
and another one with a scaling factor of two, he/she expects things to
be twice as large on the second monitor.
If we (foot) scale using DPI on the first monitor, and using the
scaling factor on the second monitor, foot will *not* look twice as
big on the second monitor (this was the old behavior of
dpi-aware=auto).
Part of #714
Render braille ourselves, instead of using font glyphs. Decoding a
braille character is easy enough; there are 256 codepoints,
represented by an 8-bit integer (i.e. subtract the Unicode codepoint
offset, 0x2800, and you’re left with an integer in the range 0-255).
Each bit corresponds to a dot. The first 6 bits represent the upper 6
dots, while the two last bits represent the fourth (and last) row of
dots.
The hard part is sizing the dots and the spacing between them.
The aim is to have the spacing between the dots be the same size as
the dots themselves, and to have the margins on each side be half the
size of the dots.
In a perfectly sized cell, this means two braille characters next to
each other will be evenly spaced.
This is however almost never the case. The layout logic currently:
* Set dot size to either the width / 4, or height / 8, depending on
which one is smallest.
* Horizontal spacing is initialized to the width / 4
* Vertical spacing is initialized to the height / 8
* Horizontal margins are initialized to the horizontal spacing / 2
* Vertical margins are initialized to the vertical spacing / 2.
Next, we calculate the number of “remaining” pixels. That is, if we
add the left margin, two dots and the spacing between, how many pixels
are left on the horizontal axis?
These pixels are distributed in the following order (we “stop” as soon
as we run out of pixels):
* If the dot size is 0 (happens for very small font sizes), increase
it to 1.
* If the margins are 0, increase them to 1.
* If we have enough pixels (need at 2 horizontal and 4 vertical),
increase the dot size.
* Increase spacing.
* Increase margins.
Closes#702
Under certain circumstances, GNOME will send multiple pointer button
press events, without any release or leave events in between.
This trips up our button tracking.
Workaround, by replacing the existing state for the pressed button
with the new state.
Previously, debug builds would assert (and thus crash), while release
builds would have multiple states for the same button,
causing (probably) issues like the title bar not being usable (as in,
cannot be dragged, buttons not working etc).
Hopefully closes#709
