When moving the viewport in the scrollback (i.e. “scrolling”), we need
to ensure the viewport is not moved past the beginning, or end, of the
scrollback.
This was previously accomplish by first limiting the number of lines
to scroll to the number of visible rows (i.e the viewport _size_), and
by adjusting the viewport after moving it, to ensure it doesn’t point
into an uninitialized scrollback area etc.
I.e. the implementation was _reactive_.
This patch rewrites the logic to be _proactive_; we now calculate
_where_ the beginning (or end) of the scrollback is, and then how many
lines there is from there, to the viewport. This is our _maximum_
number of lines to scroll.
When done correctly (which I hope this patch does), this allows us to
remove _all_ checks after moving the viewport - we already _know_ it’s
correct, and valid.
As a bonus, we can remove the old limit, where scrolling was only
allowed to be at most a single page.
With this, it is now possible to map key combos to custom escapes. The
new bindings are defined in a new section, “text-bindings”, on the
form “string=key combo”.
The string can consist of printable characters, or \xNN style hex
digits:
[text-bindings]
abcd = Control+a
\x1b[A = Control+b Control+c Control+d # map ctrl+b/c/d to UP
A foot --server instance would exit with code 0, even on failure, if
the number of currently open terminal instances were 0.
This is because ‘ret’ assumed failure, and then tried to set it to
‘success’ after the even loop had terminated, basted on the server’s
current state.
Fix by:
* set ‘ret’ to success just before entering the event loop
* set ‘ret’ to failure when we detect an FDM failure
* don’t try to second-guess success/failure after having exited the
event loop
Closes#943
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.
