It means that st doesn’t have any terminfo entry on your system. Chances are
you did not `make install`. If you just want to test it without installing it,
-you can manualy run `tic -s st.info`.
+you can manually run `tic -sx st.info`.
## Nothing works, and nothing is said about an unknown terminal!
$ printf '\033[?1h\033=' >/dev/tty
or
- $ echo $(tput smkx) >/dev/tty
+ $ tput smkx
In the case of bash, readline is used. Readline has a different note in its
manpage about this issue:
## How can I use meta in 8bit mode?
- St supports meta in 8bit mode, but the default terminfo entry doesn't
- use this capability. If you want it, you have to use the 'st-meta' value
- in TERM.
+St supports meta in 8bit mode, but the default terminfo entry doesn't
+use this capability. If you want it, you have to use the 'st-meta' value
+in TERM.
## I cannot compile st in OpenBSD
-OpenBSD lacks of librt, despite it begin mandatory in POSIX
+OpenBSD lacks librt, despite it being mandatory in POSIX
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13>.
If you want to compile st for OpenBSD you have to remove -lrt from config.mk, and
st will compile without any loss of functionality, because all the functions are
included in libc on this platform.
-## Backspace key does not work
+## The Backspace Case
+
+St is emulating the Linux way of handling backspace being delete and delete being
+backspace.
This is an issue that was discussed in suckless mailing list
-<http://lists.suckless.org/dev/1404/20697.html>:
+<http://lists.suckless.org/dev/1404/20697.html>. Here is why some old grumpy
+terminal users wants its backspace to be how he feels it:
Well, I am going to comment why I want to change the behaviour
of this key. When ASCII was defined in 1968, communication
[1] http://www.ibb.net/~anne/keyboard.html
[2] http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-5.html
+## But I really want the old grumpy behaviour of my terminal
+
+Apply [1].
+
+[1] http://st.suckless.org/patches/delkey
+
+## BadLength X error in Xft when trying to render emoji
+
+Xft makes st crash when rendering color emojis with the following error:
+
+"X Error of failed request: BadLength (poly request too large or internal Xlib length error)"
+ Major opcode of failed request: 139 (RENDER)
+ Minor opcode of failed request: 20 (RenderAddGlyphs)
+ Serial number of failed request: 1595
+ Current serial number in output stream: 1818"
+
+This is a known bug in Xft (not st) which happens on some platforms and
+combination of particular fonts and fontconfig settings.
+
+See also:
+https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6
+https://bugs.freedesktop.org/show_bug.cgi?id=107534
+https://bugzilla.redhat.com/show_bug.cgi?id=1498269
+
+The solution is to remove color emoji fonts or disable this in the fontconfig
+XML configuration. As an ugly workaround (which may work only on newer
+fontconfig versions (FC_COLOR)), the following code can be used to mask color
+fonts:
+
+ FcPatternAddBool(fcpattern, FC_COLOR, FcFalse);
+
+Please don't bother reporting this bug to st, but notify the upstream Xft
+developers about fixing this bug.