|
|
## Why does st not handle utmp entries? |
|
|
|
|
|
Use the excellent tool of [utmp](http://git.suckless.org/utmp/) for this task. |
|
|
|
|
|
## 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`. |
|
|
|
|
|
## 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 launching 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? |
|
|
|
|
|
Using a terminal multiplexer. |
|
|
|
|
|
* `st -e tmux` using C-a [ |
|
|
* `st -e screen` using C-a ESC |
|
|
|
|
|
## 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[?1hE= and rmkx=E[?1lE>, 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: |
|
|
|
|
|
$ printf "<EFBFBD>33?1h<EFBFBD>33=" >/dev/tty |
|
|
|
|
|
or |
|
|
$ echo $(tput smkx) >/dev/tty |
|
|
|
|
|
In the case of bash readline is used. Readline has a different note in its |
|
|
manpage about this issue: |
|
|
|
|
|
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. |
|
|
|
|
|
If you are using zsh, then read the zsh FAQ |
|
|
<http://zsh.sourceforge.net/FAQ/zshfaq03.html#l25>: |
|
|
|
|
|
It should be noted that the O / [ confusion can occur with other keys |
|
|
such as Home and End. Some systems let you query the key sequences |
|
|
sent by these keys from the system's terminal database, terminfo. |
|
|
Unfortunately, the key sequences given there typically apply to the |
|
|
mode that is not the one zsh uses by default (it's the "application" |
|
|
mode rather than the "raw" mode). Explaining the use of terminfo is |
|
|
outside of the scope of this FAQ, but if you wish to use the key |
|
|
sequences given there you can tell the line editor to turn on |
|
|
"application" mode when it starts and turn it off when it stops: |
|
|
|
|
|
function zle-line-init () { echoti smkx } |
|
|
function zle-line-finish () { echoti rmkx } |
|
|
zle -N zle-line-init |
|
|
zle -N zle-line-finish |
|
|
|
|
|
Putting these lines into your .zshrc will fix the problems.
|
|
|
|
