This is done by:
* Not limiting the number of times we try to read from the PTY when
we’ve have POLLHUP
* Not requiring the entire the previous read to have filled our
buffer.
* Not erroring out on EIO.
Defensive programming; output_geometry() etc are typically only called
once for an output instance. But let’s ensure we’re not leaking memory
if it’s called more than once.
This ensures we don’t accidentally reference them from places we
shouldn’t.
Unfortunately, binding_action_map[] (for “normal” key bindings) cannot
easily be made function local since it is used when parsing both key-
and mouse bindings (i.e. it’s used in multiple functions).
Don’t call has_key_binding_collisions() with ‘binding_action_map’
unconditionally; use the provided ‘action_map’ instead.
This fixes wrong error messages for key combo collisions in key
binding sections other than the regular “key-bindings”.
sixel_color_set() is called when the number of (sixel) color registers
is changed.
It frees the current palette, and changes the “palette size” variable.
Originally, we only had a single palette. This is the one free:d by
sixel_color_set().
Later, we added support for private vs. shared palettes. With this
change, we now have one palette that is “never” free:d (the shared
one), and a private palette that is always free:d after a sixel has
been emitted.
‘sixel.palette’ is a pointer to the palette currently in use, and
should only be accessed **while emitting a sixel**.
This is the pointer sixel_color_set() free:d. So for example, if
‘sixel.palette’ pointed to the shared palette, we’d free the shared
palette. But, we didn’t reset ‘sixel.shared_palette’, causing a double
free later on.
Closes#427
There were two issues with it:
* Not all applications decode the sequence into a set of modifiers +
key, but use a fixed sequence -> combo mapping, that we broke.
* There were unforeseen issues with e.g. F1-12, where the modifier
were removed from combos like Ctrl+F12, or Alt+F12. The reason is
simple; XKB tells us that Ctrl, or Alt, is a consumed modifier. Now,
_why_ it thinks that is a different story.
This reverts 6cd72bdee6Closes#425
While we don’t (yet) have any unit tests for foot, users can build
foot with e.g. fcft and/or tllist as sub-projects. *They* have tests,
and when doing PGO builds, those test binaries *must* be executed, or
we get link failures in the final build.
0 is a perfectly valid row number, and if max_non_empty_row_no==0,
that means we have *1* sixel row, and after trimming the image, the
image will have a height of 6 pixels.
If the sixel sequence is empty (or at least doesn’t emit any non-empty
pixels), then trimming the image should result in an image height of
0.
When max_non_empty_row_no is initialized to -1, it will still have
that value in unhook(), which makes the final image height 0.
There are cyclic dependencies between the log, debug and xmalloc
libraries. While having them as separate static libraries work, as
long as consumers of them link against all of them, having them in a
single library feels slightly better.
The text was describing the original behavior, where output scaling
was completely ignored, and tacked on a “btw, starting with
foot-1.6...”.
Now, simply describe the current behavior, and be more clear about
_how_ dpi-aware can be changed.
LLVM/Clang 11.x throws errors for _files_ without any profiling data:
error: ../../async.c: Function control flow change detected (hash mismatch) async_write Hash = 72057641800614222 [-Werror,-Wbackend-plugin]
This caused multiple issues with the current PGO instructions:
* The `pgo` binary failed to link with `meson configure -Db_pgo=use`
when doing a full PGO build (since it isn't used in this case);
* `footclient` fails to link for the same reason.
* `foot` fails to link for the same reason in **partial** PGO builds.
The solution is to make sure all binaries that are built in the final
phase (`-Db_pgo=use`) have been executed in the _generate_ phase.
Doing this also means we can drop `-Wno-missing-profile` and friends.
Also add `--sixel` to the `generate-alt-random-writes` command line in
the description for a full PGO build.
Closes#418
Before this, we assumed gcc was being used. The build would fail if
clang (or something else) was used.
Now, we check whether we’re compiling with gcc or clang, and disable
PGO if it’s neither of them.
Furthermore, we’re now adding the necessary flags needed to do PGO
with clang.
Note that ‘llvm-profdata’, from the ‘llvm’ package is needed for
PGO:ing with clang. PGO is disabled if it isn’t available. It would be
nice to have ‘llvm’ as an optional make dependency, but PKGBUILDs
doesn’t appear to support such a thing.
Finally, the -Wno-missing-profile flag, and its friends, have been
removed; instead we execute “footclient --version” (and “foot
--version”, in partial PGO builds) to ensure all generated binaries
have been executed before we do the final build (with
-Db_pgo=use). This fixes build failures with clang >= 11.x.
This is the only time it’s needed.
In non-PGO builds, it is completely unnecessary, and we’re only
wasting CPU cycles building it.
In full PGO builds, with -Db_pgo=use, we get link warnings and/or
failures, depending on compiler, since the pgo binary hasn’t been
executed.
