Roberto E. Vargas Caballero schrieb am 18.03.2014 12:30:
> You should read terminfo(5)
>
> > > I have no idea what the differences between home and khome are or why
> two
> > > versions for home exist. Anyway, here are my results:
>
> home is the definition for the home sequence, is the sequence that a
> program
> has to sent to the terminal to get the home function, and khome is the
> sequence generated by the key home, that depend of the keypad mode. There
> are two modes:
>
> - keypad mode: In this mode the keys generate the same sequence that
> the function they are labelled. In the case of home key
> st generates ^[[H, that is the value of the home
> sequence.
>
> - application mode: In this mode the keys generate some sequence that
> identify them, in the case of st ^[1~, that is the value
> of the sequence khome, so any application can detect
> this key was pressed.
>
>
> > >
> > > CTRL-v + HOME:
> > >
> > > | zsh | bash | ksh |
> > > +-------+-------+-------+
> > > st | ^[[H | ^[[H | ^[[H | <- works in bash
> > > xterm | ^[OH | ^[[H | ^[[H | <- works in zsh and bash
> > > rxvt | ^[[7~ | ^[[7~ | ^[[7~ | <- never works
>
> The next point you are loosing and you can find in terminfo(5) is the
> sequences
> rmkx and smkx:
>
> 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, give these codes as smkx and rmkx. Otherwise
> the keypad is assumed to always transmit.
>
> > > CTRL-v + DEL:
> > >
> > > | zsh | bash | ksh |
> > > +-------+-------+-------+
> > > st | ^[[P | ^[[P | ^[[P | <- never works
> > > xterm | ^? | ^? | ^? | <- deletes backwards in zsh, bash; not in ksh
> > > rxvt | ^[[3~ | ^[[3~ | ^[[3~ | <- works in zsh, bash; not in ksh
>
> so, any program must send the smkx sequence before of testing is the key
> was pressed, but there are some ugly applications (as for example zsh)
> that don't do it. All this question are answer in the FAQ [1] , and in the
> case of bash even it is explained how to fix it.
>
> > Maybe the problem is rooted in different shell versions emitting
> different key
> > codes:
>
> There are some shells that have bugs, and another that don't have bugs.
>
> I begin to be a bit tired of answer the same question all the times.
>
> Regards,
>
>
> [1] :http://st.suckless.org/
>
> --
> Roberto E. Vargas Caballero
>
>
Hi Roberto,
thanks for your email. Sorry for the trouble, i should have read the FAQ
first. As it's a bit hidden on the page, i suggest linking to it in the
side-navigation bar (pushed a patch to the repo).
Now to my problem: I investigated a bit further, tried the hint from the FAQ
and also checked the zshrc that is installed by default on debian. Here's a
code snippet from the debian zshrc doing the same as the FAQ suggests:
debian$ sed -n '71,89p' /etc/zsh/zshrc
# Make sure the terminal is in application mode, when zle is
# active. Only then are the values from $terminfo valid.
if (( ${+terminfo[smkx]} )) && (( ${+terminfo[rmkx]} )); then
function zle-line-init () {
emulate -L zsh
printf '%s' ${terminfo[smkx]}
}
function zle-line-finish () {
emulate -L zsh
printf '%s' ${terminfo[rmkx]}
}
zle -N zle-line-init
zle -N zle-line-finish
else
for i in {s,r}mkx; do
(( ${+terminfo[$i]} )) || debian_missing_features+=($i)
done
unset i
fi
Now, the problem on openbsd is that there is no entry for {r,s}mkx once it gets
installed with tic (checked with 'infocmp st'). I have no idea why, and will
ask on their mailing list.
Thanks again for your help
Nils
