Re: [dev] [st] some more random fixes

From: Markus Teich <markus.teich_AT_stusta.mhn.de>
Date: Wed, 26 Jun 2013 22:38:43 +0200

fyi

--Markus

Betreff: Re: some more random fixes
Datum: Wed, 26 Jun 2013 19:19:25 +0000 (UTC)
Von: Thorsten Glaser <tg_AT_mirbsd.de>
An: Markus Teich <markus.teich_AT_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.
>
Received on Wed Jun 26 2013 - 22:38:43 CEST