The meson command line option -Dcustom-terminfo-install-location has
been changed in the following ways:
* If unset, $datadir/terminfo is used, and TERMINFO is *not* exported
* If set, that value (relative to $prefix) is used, and TERMINFO *is*
exported.
* The special value ‘no’ is removed.
-Ddefault-terminfo now also changes the terminfo names generated when
-Dterminfo=enabled.
Furthermore, the documentation for the TERMINFO environment variable
has been removed from the foot.1 and footclient.1 man pages (but as
mentioned above, foot *will* still set it if
-Dcustom-terminfo-install-location has been used).
INSTALL.md has been updated to now recommend using ncurses’ terminfo
definitions, if available. But also to document the other
alternatives; installing the terminfo definitions in a custom
location, or installing them with a diferent name. It also describes
the general problem, and the disadvantages of each alternative (but
without going into too much depth).
As of 2021-07-31, ncurses ships its own version of foot’s terminfo.
Since:
* It doesn’t have the non-standard Sync,Tc,setrgbf,setrgbb
capabilities.
* It doesn’t set hs,fsl,dsl (statusbar).
* We want to be able to update our termminfo without waiting for an
ncurses release.
* Foot should be installable and usable on Linux systems that doesn’t
have the latest ncurses.
we still want to ship our own version. We can however not install it
to the default terminfo location (e.g. /usr/share/terminfo), since it
will collide with the ncurses provided files.
Our options are to either rename our terminfo to something else, or to
keep the name, but install our terminfo files somewhere else.
The first option would be the easy one. However, I think it makes
sense to use the same name. For example, a user that SSH’s into a
remote system that does *not* have our own version installed,
but *does* have the ncurses one, will gracefully fall back to that
one, which is better than manually having to set
e.g. TERM=xterm-256color.
Now, if we want to use the same name, we need to install it somewhere
else. But where? And how do we ensure our version is preferred over
the ncurses one?
I opted to $datadir/foot/terminfo (e.g. /usr/share/foot/terminfo) by
default. It makes it namespaced to foot (i.e. we’re not introducing a
new “standard” terminfo location), thus guaranteeing it wont collide
with ncurses.
To enable applications to find it, we export TERMINFO_DIRS. This is a
list of *additional* directories to search for terminfo files. If it’s
already defined, we *append* to it.
The nice thing with this is, if there’s no terminfo in that
location (e.g. when you SSH into a remote), the default terminfo
location is *also* searched. But only *after* having searched through
TERMINFO_DIRS.
In short: our version is preferred, but the ncurses one (or an older
version of our terminfo package!) will be used if ours cannot be
found.
To enable packagers full control over the new behavior, the existing
meson command line options have been modified, and a new option added:
-Dterminfo=disabled|enabled|auto: *build* and *install* the terminfo
files.
-Dcustom-terminfo-install-location=<path>: *where* the terminfo files
are expected to be found.
This *needs* to be set *even* if -Dterminfo=disabled. For example, if
the packaging script builds and packages the terminfo files separate
from the regular foot build. The path is *relative to $prefix*, and
defaults to $datadir/foot/terminfo.
This is the value that will be appended to TERMINFO_DIRS. Note that
you can set it to ‘no’, in which case foot will *not* set/modify
TERMINFO_DIRS. Only do this if you don’t intend to package foot’s
terminfo files at all (i.e. you plan on using the ncurses ones only).
-Ddefault-terminfo=foot. Allows overriding the default TERM
value. This should only be changed if the target platform doesn’t
support terminfo files.
Closes#671
This option specifies the characters allowed in the auto-detected
URLs.
Any character not in this set constitutes an URL delimiter, and will
never be included in auto-detected URLs.
This option does not affect OSC-8 URLs.
Closes#654
This patch adds a `confined` flag to each cell to track if the last
rendered glyph bled into it's right neighbor. To keep things simple,
bleeding into any other neighbor cell than the immediate right one is
not allowed. This should cover most use cases.
Before rendering a row we now do a prepass and mark all cells unclean
that are affected by a bleeding neighbor. If there are consecutive
bleeding cells, the whole group must be re-rendered even if only a
single cell has changed.
The patch also deprecates both old overflowing glyph options
*allow-overflowing-double-width-glyphs* and *pua-double-width* in favor
of a single new one named *overflowing-glyphs*.
This means that logging will be completely disabled until log_init()
has been called, which is useful to prevent log spam when running
UNITTEST{} blocks in debug builds.
Note that this doesn't change the default log level at runtime, which
was already being set to LOG_CLASS_INFO in main.c and client.c.
The new log level is also exposed to the command-line interface as
`--log-level=none`, which allows disabling logging entirely.
This option controls the foreground color of the
minimize/maximize/close buttons. I.e. the color used to draw the
minimize/maximize/close glyphs.
It defaults to default background color.
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.
Allow any configuration option to be overridden with -o/--override
'section.key=value' arguments, as suggested in #554
update completitions for override
slight refactoring to ease footclient support
When enabled, PUA (Private Usage Area) codepoints are always treated
as double-width glyphs, regardless of the actual glyph width.
Requires allow-overflowing-double-width-glyphs=yes
This allows you to include sub-configurations. For example, theme
files.
The ‘include’ directive is a top-level keyword. I.e. it cannot be used
inside sections.
* The included file must be specified with an absolute path
* The included file is parsed in its own scope
* Nested includes are allowed
* Multiple include directives are allowed
Closes#555
