fyi
--Markus
Betreff: Re: some more random fixes
Datum: Wed, 26 Jun 2013 19:19:25 +0000 (UTC)
Von: Thorsten Glaser <t...@mirbsd.de>
An: Markus Teich <markus.te...@stusta.mhn.de>
Markus Teich dixit:
> I don't know if it is that uncommon.
Answer below².
> For the keys
Let me make this a table and rotate it by 90°:
st urxvt xterm xfce4-t notes
Ins ^[[4h ^[[2~ ^[[2~ ^[[2~ not used by mksh
Del ^[[P ^[[3~ ^[[3~ ^[[3~ see below²
Home ^[[H ^[[1~ ^[[H ^[OH both¹ supported
End ^[[4~ ^[[4~ ^[[F ^[OF both¹ supported
PgDn ^[[5~ ^[[5~ ^[[5~ ^[[5~ all the same
PgUp ^[[6~ ^[[6~ ^[[6~ ^[[6~ all the same
① ^[[ and ^[O and ^X all map to prefix-2 so are the same internally
> So there does not seem to be a standard
Actually, sane OS distributions define their standards.
I was only aware of the standards for OpenBSD until I
recently, by accident (not thinking of this issue) saw
what the Debian Policy has to say on this.
tl;dr: it mandates terminals to send ^[[3~ for Del (and
mandates a whole bunch of other things), just like BSD.
This also means that versions of st packaged in Debian
will send ^[[3~ (or are RC-buggy).
⇒ ① I will *not* add ^[[P as binding for Del to mksh
itself, but users of an unpatched st can do that
themselves by adding
bind '^[[P=delete-char-forward'
to their ~/.mkshrc (or other $ENV) file.
Please forward this resolution to the st developers.
bye,
//mirabilos
Am 23.06.2013 01:19, schrieb Roberto E. Vargas Caballero:
On Sat, Jun 22, 2013 at 11:39:19PM +0200, Markus Teich wrote:
And of course i only did this patch for
XK_KP_Delete and forgot about
XK_Delete.
Sorry but these patches are incorrects.
+ { XK_Delete, XK_ANY_MOD, "\033[3~", 0, 0, 0},
{ XK_Delete, XK_ANY_MOD, "\033[P", -1, 0, 0},
- { XK_Delete, XK_ANY_MOD, "\033[3~", +1, 0, 0},
This change causes that Delete always generates \033[3~, even in ascii mode,
where it must generates \033[P (the sequence for deleting a char). Like is
said in the FAQ it is a bug in mksh, because it doesn't set the terminal in
keypad mode before testing against Delete. You should look in the
documentation of your shell, because it must provide a way of fixing its
bug, or in other case you could send a bug notification to them.
When terminal is in ascii mode it generates sequences which the own terminal
understand for such functions. You can test how works the ascii mode with:
rmkx && stty -echo cbreak min 1 && clear && cat >/dev/tty
after running the command you will see how you can edit a page in the
editor (remember run 'reset' after the test), and all the keys works as
expected:
- Insert: sets the terminal in insert mode instead of replace mode
- Shift + Insert (only if it is not enabled the shortcut for copy):
sets the terminal in replace mode.
- Control + Insert: Insert a new line in the position where is
located the cursor
- Supr: delete the character under the cursor
- Control + Delete : clears the screen
- Shift + Delete: clears the line
- Home: goes to first position in the screen
- Control + End : Clears until end of screen
- Shift + End : clears until end of line
Like I said, this works due to the correct generation of ascii sequences,
and like it is said in terminfo man page and in the FAQ:
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.
Like our terminfo entry defines rmkx and smkx all the programs which want
detect these keys directly must write smkx before of testing them.
