|
|
|
|
|
--
|
|
|
|
|
|
Why does st not handle utmp entries?
|
|
|
|
|
|
|
|
|
|
|
|
Use the excellent tool of utmp[0] for this task.
|
|
|
|
|
|
|
|
|
|
|
|
[0] http://git.suckless.org/utmp/
|
|
|
|
|
|
--
|
|
|
|
|
|
Some _random program_ complains that st is unknown/not
|
|
|
|
|
|
recognised/unsupported/whatever!
|
|
|
|
|
|
|
|
|
|
|
|
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 in st dir. It will compile st.info into a
|
|
|
|
|
|
fully working local terminfo description. You can delete it when you’re done.
|
|
|
|
|
|
--
|
|
|
|
|
|
Nothing works, and nothing is said about an unknown terminal!
|
|
|
|
|
|
|
|
|
|
|
|
* Some programs just assume they’re running in xterm i.e. they don’t rely on
|
|
|
|
|
|
terminfo. What you see is the current state of the “xterm compliance”.
|
|
|
|
|
|
* Some programs don’t complain about the lacking st description and default to
|
|
|
|
|
|
another terminal. In that case see the question about terminfo.
|
|
|
|
|
|
--
|
|
|
|
|
|
I get some weird glitches/visual bug on _random program_!
|
|
|
|
|
|
|
|
|
|
|
|
Try lauching it with a different TERM: $ TERM=xterm myapp. toe(1) will give
|
|
|
|
|
|
you a list of available terminals, but you’ll most likely switch between
|
|
|
|
|
|
xterm, st or st-256color. The default value for TERM can be changed in
|
|
|
|
|
|
config.h (TNAME).
|
|
|
|
|
|
--
|
|
|
|
|
|
How do I scroll back up?
|
|
|
|
|
|
|
|
|
|
|
|
Invoke st with a screen multiplexer like GNU screen[0] or tmux[1].
|
|
|
|
|
|
st -e screen works better for text reflowing. To enter screen’s scroll
|
|
|
|
|
|
back mode aka “copy mode”, it’s C-a ESC. You probably want defscrollback
|
|
|
|
|
|
10000 in your ~/.screenrc too.
|
|
|
|
|
|
|
|
|
|
|
|
[0] http://en.wikipedia.org/wiki/GNU_Screen
|
|
|
|
|
|
[1] http://en.wikipedia.org/wiki/Tmux
|
|
|
|
|
|
--
|
|
|
|
|
|
Why doesn't the Del key work in some programs?
|
|
|
|
|
|
|
|
|
|
|
|
Taken from the terminfo manpage:
|
|
|
|
|
|
|
|
|
|
|
|
If the terminal has a keypad that transmits codes when the keys
|
|
|
|
|
|
are pressed, this information can be given. Note that it is not
|
|
|
|
|
|
possible to handle terminals where the keypad only works in
|
|
|
|
|
|
local (this applies, for example, to the unshifted HP 2621 keys).
|
|
|
|
|
|
If the keypad can be set to transmit or not transmit, tive these
|
|
|
|
|
|
codes as smkx and rmkx. Otherwise the keypad is assumed to
|
|
|
|
|
|
always transmit.
|
|
|
|
|
|
|
|
|
|
|
|
In the st case smkx=\E[?1h\E= and rmkx=\E[?1l\E>, so it is mandatory that
|
|
|
|
|
|
applications which want to test against keypad keys, have to send these
|
|
|
|
|
|
sequences.
|
|
|
|
|
|
|
|
|
|
|
|
But buggy applications like bash and irssi for example don't do this. A fast
|
|
|
|
|
|
solution for them is to use the following command:
|
|
|
|
|
|
|
|
|
|
|
|
$ echo ^[?1h^[= >/dev/tty
|
|
|
|
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
$ echo $(tput smkx) >/dev/tty
|
|
|
|
|
|
|
|
|
|
|
|
In the case of bash it is using readline, which has a different not in its
|
|
|
|
|
|
manpage:
|
|
|
|
|
|
|
|
|
|
|
|
enable-keypad (Off)
|
|
|
|
|
|
When set to On, readline will try to enable the
|
|
|
|
|
|
application keypad when it is called. Some systems
|
|
|
|
|
|
need this to enable arrow keys.
|
|
|
|
|
|
|
|
|
|
|
|
Adding this option to your .inputrc will fix the keypad problem for all
|
|
|
|
|
|
applications using readline.
|
|
|
|
|
|
--
|
|
|
|
|
|
|
