The other functions that deal with private modes all use 1070 for
term->sixel.use_private_palette. The xterm docs[1] also list this
param as 1070:
> Ps = 1 0 7 0 ⇒ use private color registers for each graphic
Using 1079 seems to have been a mistake in commit 4aa980a6a2.
Not doing so before calling sigaction(3) is "undefined" according to
POSIX[1]:
> Applications shall call either sigemptyset() or sigfillset() at least
> once for each object of type sigset_t prior to any other use of that
> object. If such an object is not initialized in this way, but is
> nonetheless supplied as an argument to any of pthread_sigmask(),
> sigaction(), sigaddset(), sigdelset(), sigismember(), sigpending(),
> sigprocmask(), sigsuspend(), sigtimedwait(), sigwait(), or
> sigwaitinfo(), the results are undefined.
The use of designated initializers means that sa_mask members were
still being initialized, but sigset_t is an opaque type and implicit
initialization doesn't necessarily produce the same results as using
sigemptyset(3) (although it typically does on most implementations).
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaddset.html
This fixes a compilation error on FreeBSD:
../../foot/render.c:2055:45: error: no member named 'epoll_shim_close' in 'struct config::(anonymous at ../../foot/config.h:254:9)'
conf_color = &term->conf->csd.color.close;
~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/libepoll-shim/epoll-shim/detail/common.h:8:15:
note: expanded from macro 'close': #define close epoll_shim_close
Editors like Vim and Kakoune ship filetypes dosini and ini
respectively. Both use ";" as comment character, which is used for
example by Vim's "gq" command which wraps lines while preserving
comment prefixes.
foot only accepts # comments. I think it's desirable to stick to
a single commenting style (easier to diff configs).
Make Vim accept that by adding modeline to use the "conf"
filetype, which is for "generic Unix config files". We already
have an Emacs modeline at the top, but Vim seems to ignore it.
Kakoune doesn't have that filetype, but a patch has been
proposed to use # whenever it already occurs in the file, see
https://github.com/mawww/kakoune/pull/4537
This function allows setting a custom mouse cursor.
This is done by adding a ‘char*’ member to the term struct. When it is
non-NULL, we *always* use that pointer (the exception being when the
pointer is hidden), while the pointer is over the grid. This is
instead of the hand/beam pointers we otherwise would use.
Before this patch, wl_cursor_theme_get_cursor() was called in the FDM
hook, just before we’re about to update the mouse cursor “for real”.
This relies on seat->pointer.xcursor still being valid. This is true
as long as we’re only using our compiled-in static xcursor names, but
not otherwise.
Now, we call wl_cursor_theme_get_cursor() in render_xcursor_set(). At
this point, we *know* seat->pointer.xcursor is valid.
There is a slight chance of added overhead here, if the client
application is switching mouse grabbing on/off rapidly. Before, the
calls to wl_cursor_theme_get_cursor() would automatically be
throttled.
However, the main point of delaying the actual pointer update to the FDM
hook is to throttle the *Wayland* calls. And this is still happening:
wl_cursor_theme_get_cursor() is client-side only.
We calculated the ‘start’ row by adding the number of screen rows to
the current grid offset. This works in most cases. But not when the
offset is close to the wrap-around.
This triggered a crash when we tried to access a row number larger
than the number of available grid rows.
Fix by bounding the start row to the number of grid rows.
This unearthed a second bug, where trying to extract the scrollback
resulted in nothing getting copied.
The extraction logic did:
for (r = start; r != (end + 1); r++)
....
This works, as long as end isn’t start-1. When we try to extract the
entire scrollback, it _is_ start-1.
Fix by rewriting the loop logic to check for r==end *after* copying
the row contents, but *before* incrementing r.
Closes#926
When iterating the characters in a selection, we want to go from the
“start” to the “end”, where start is the upper left-most character,
and “end” is the lower right-most character.
There are two things to consider:
* The ‘start’ coordinate may actually sort after the ‘end’
coordinate (user selected from bottom of the window and upward)
* The scrollback wraparound.
What we do is calculate both the star and end coordinates’
scrollback-start relative row numbers. That is, the number of rows
from the beginning of the scrollback. So if the very first
row (i.e. the oldest) in the scrollback is selected, that has the
scrollback-start relative number “0”.
Then we loop from whichever (start or end coordinate) is highest up in
the scrollback, to the “other” coordinate.
This fixes a crash caused by the selection’s pivot point not being
translated during reflow.
While we could simply reflow the pivot point as well, testing shows
irregular behavior with ongoing selections across window resizes, with
different compositors behaving differently.
For now, we simply finalize the selection, instead of trying to handle
ongoing selections.
Closes#922
