inconsistent bindings of backspace and delete between X and xterm

inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

[I read bug-gnu-emacs via the gatewayed newsgroup.  Please cc me on
any followups, if possible. --rdh]

I was experimenting with emacs 21.3 running under X and then inside
xterm, and I observe the following behaviour.  In all cases, I started
emacs with the -q flag.

1. Under X, the backspace and delete keys generate the respective
   window-system events, each of which is mapped to DEL via the
   function-key-map, which is then bound to
   `delete-previous-character'.

2. Under xterm version 4.2.99.903(174), backspace sends DEL and delete
   sends `ESC [ 3 ~'.  Emacs treats DEL, of course, as
   `delete-previous-character', but `ESC [ 3 ~' is mapped to the event
   <deletechar>, which is bound to `delete-char'.

This behaviour is inconsistent.  In each case, emacs can distinguish
between the Delete and Backspace keys, but in one environment they
behave, and in the other, differently.  Also, is there any reason why
`ESC [ 3 ~' shouldn't be mapped to <delete> instead of <deletechar>.

Is this intentional?  I don't really care which way the inconsistency
is resolved, but I think it should be.

Dale Hagglund.

Re: inconsistent bindings of backspace and delete between X and xterm

[Andreas Schwab]

Dale Hagglund <rdh@yottayotta.com> writes:

> [I read bug-gnu-emacs via the gatewayed newsgroup.  Please cc me on
> any followups, if possible. --rdh]
>
> I was experimenting with emacs 21.3 running under X and then inside
> xterm, and I observe the following behaviour.  In all cases, I started
> emacs with the -q flag.
>
> 1. Under X, the backspace and delete keys generate the respective
>    window-system events, each of which is mapped to DEL via the
>    function-key-map, which is then bound to
>    `delete-previous-character'.
>
> 2. Under xterm version 4.2.99.903(174), backspace sends DEL and delete
>    sends `ESC [ 3 ~'.  Emacs treats DEL, of course, as
>    `delete-previous-character', but `ESC [ 3 ~' is mapped to the event
>    <deletechar>, which is bound to `delete-char'.
>
> This behaviour is inconsistent.  In each case, emacs can distinguish
> between the Delete and Backspace keys, but in one environment they
> behave, and in the other, differently.  Also, is there any reason why
> `ESC [ 3 ~' shouldn't be mapped to <delete> instead of <deletechar>.

This is a property of the terminal description.  For xterm it contains
`kdch1=\E[3~' (terminfo) or `kD=\E[3~' (termcap), thus `ESC [ 3 ~' is
mapped to <deletechar>.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: inconsistent bindings of backspace and delete between X and xterm

[Eli Zaretskii]

> From: Dale Hagglund <rdh@yottayotta.com>
> Date: Fri, 06 Feb 2004 20:35:13 -0700
> 
> 1. Under X, the backspace and delete keys generate the respective
>    window-system events, each of which is mapped to DEL via the
>    function-key-map, which is then bound to
>    `delete-previous-character'.

This is wrong: the <delete> key should not be mapped to DEL.  It
should be mapped to C-d, and thus run `delete-char', like it does in
xterm.

What OS is that?  Does it help to experiment with
normal-erase-is-backspace-mode?

> In all cases, I started emacs with the -q flag.

Did you also use the --no-site-file switch?  If not, can you use it in
addition to -q and see if that changes anything?

Re: inconsistent bindings of backspace and delete between X and xterm

[Andreas Schwab]

"Eli Zaretskii" <eliz@elta.co.il> writes:

>> From: Dale Hagglund <rdh@yottayotta.com>
>> Date: Fri, 06 Feb 2004 20:35:13 -0700
>> 
>> 1. Under X, the backspace and delete keys generate the respective
>>    window-system events, each of which is mapped to DEL via the
>>    function-key-map, which is then bound to
>>    `delete-previous-character'.
>
> This is wrong: the <delete> key should not be mapped to DEL.  It
> should be mapped to C-d, and thus run `delete-char', like it does in
> xterm.

Note that term/xterm.el maps "\e[3~" to [delete] by default (subject to
termcap settings).  That should probably be changed to [deletechar].

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> This is wrong: the <delete> key should not be mapped to DEL.  It
> should be mapped to C-d, and thus run `delete-char', like it does in
> xterm.
>
> What OS is that?  Does it help to experiment with
> normal-erase-is-backspace-mode? . . . .  Did you also use the
> --no-site-file switch?  If not, can you use it in addition to -q and
> see if that changes anything?

The behaviour is the same with --no-site-file.  To give a bit more
information, I'm running my own build of 21.3 with no customizations
under redhat 9 with linux kenel 2.4.20.  I just checked the officially
installed emacs, 21.2, and it appears to behave the same way.

When I enable normal-erase-is-backspace-mode, things work as you say.
However, mapping <delete> to C-d still leaves a minor inconsistency
between <delete> and M-<delete>: the former deletes characters
forward, and the still deletes words backwards.

Something else that may be worth mentioning: I'm running all these
emacses inside a vncserver session.  I noticed in the description of
normal-erase-is-backspace, it says that it's default setting depends
on the keyboard.  Perhaps the vncserver's virtual keyboard isn't quite
responding as emacs expects?

Dale.

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

Andreas Schwab <schwab@suse.de> writes:

> Note that term/xterm.el maps "\e[3~" to [delete] by default (subject
> to termcap settings).  That should probably be changed to
> [deletechar].

Hmmm, in my version of term/xterm.el (emacs 21.3), there no entry at
all for `ESC [ 3 ~'.  Is this recent in CVS emacs?

Dale.

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

Andreas Schwab <schwab@suse.de> writes:

> Dale Hagglund <rdh@yottayotta.com> writes:

>> Also, is there any reason why `ESC [ 3 ~' shouldn't be mapped to
>> <delete> instead of <deletechar>.

[I'm not quite what part of my message your response referred to, but
I'm assuming it's to the sentence above.]

> This is a property of the terminal description.  For xterm it
> contains `kdch1=\E[3~' (terminfo) or `kD=\E[3~' (termcap), thus `ESC
> [ 3 ~' is mapped to <deletechar>.

I poked around a bit in term/*.el but I didn't see where the termcap
interpretation is happening.  That aside, wouldn't it still be better
to use the generate the same <delete> function key for for the same
physical key both under X and xterm (or a real vt220, for that
matter)?  

Dale.

Re: inconsistent bindings of backspace and delete between X and xterm

[Andreas Schwab]

Dale Hagglund <rdh@yottayotta.com> writes:

> Hmmm, in my version of term/xterm.el (emacs 21.3), there no entry at
> all for `ESC [ 3 ~'.  Is this recent in CVS emacs?

Not recent, but it has been added after 21.3.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: inconsistent bindings of backspace and delete between X and xterm

[Andreas Schwab]

Dale Hagglund <rdh@yottayotta.com> writes:

> I poked around a bit in term/*.el but I didn't see where the termcap
> interpretation is happening.

See src/term.c:term_get_fkeys_1.

> That aside, wouldn't it still be better to use the generate the same
> <delete> function key for for the same physical key both under X and
> xterm (or a real vt220, for that matter)?

Emacs has to depend on the terminal information database.  There is no way
to find out the physical location of a key in termcap/terminfo.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: inconsistent bindings of backspace and delete between X and xterm

[Thomas Dickey]

Andreas Schwab <schwab@suse.de> wrote:

> This is a property of the terminal description.  For xterm it contains
> `kdch1=\E[3~' (terminfo) or `kD=\E[3~' (termcap), thus `ESC [ 3 ~' is
> mapped to <deletechar>.

\E[3~ is conventionally used to delete forward.
The choice of BS or DEL for deleting backward depends on the user.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

Andreas Schwab <schwab@suse.de> writes:

> Emacs has to depend on the terminal information database.  There is no way
> to find out the physical location of a key in termcap/terminfo.

Sorry, I'm not making myself very clear.  I realize that emacs has to
depend on the termcap or terminfo entry, and that it doesn't know
anything about the physical keyboard layout.

My question boils down to this: Why not map the kdch1/kD sequence to
<delete> instead of <deletechar>?  Wouldn't that make bindings like

        (global-set-key [delete] 'what-ever)

work the same both under X and within xterm or other terminal
emulators?  Please forgive me if I'm missing something blindingly
obvious here.

Dale.

Re: inconsistent bindings of backspace and delete between X and xterm

[Eli Zaretskii]

> From: Dale Hagglund <rdh@yottayotta.com>
> Date: Sat, 07 Feb 2004 17:32:16 -0700
> 
> My question boils down to this: Why not map the kdch1/kD sequence to
> <delete> instead of <deletechar>?  Wouldn't that make bindings like
> 
>         (global-set-key [delete] 'what-ever)
> 
> work the same both under X and within xterm or other terminal
> emulators?  Please forgive me if I'm missing something blindingly
> obvious here.

Nothing is ever obvious in the key-binding arcana... ;-)

IIRC, it's the other way around: <delete> was there before
<deletechar>, since it worked first in a windowed Emacs.  So it's
xterm and other terminals that are chasing window-system.  I may be
wrong, though.

In any case, the reason <delete> is mapped to C-d is so you could use
C-d on any text terminal and get the same results.

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

[Sorry for following up to my own reply. --rdh]

Dale Hagglund <rdh@yottayotta.com> writes:

> "Eli Zaretskii" <eliz@elta.co.il> writes:

>> This is wrong: the <delete> key should not be mapped to DEL.  It
>> should be mapped to C-d, and thus run `delete-char', like it does
>> in xterm.

[In the original email I provided some more details about my setup
here.]

Do you have any thoughts on why I might be getting incorrect default
behaviour?  Where might I look to try to track down what's going on?

Dale.

Re: inconsistent bindings of backspace and delete between X and xterm

[Eli Zaretskii]

> From: Dale Hagglund <rdh@yottayotta.com>
> Date: Tue, 10 Feb 2004 17:13:53 -0700
> 
> >> This is wrong: the <delete> key should not be mapped to DEL.  It
> >> should be mapped to C-d, and thus run `delete-char', like it does
> >> in xterm.
> 
> [In the original email I provided some more details about my setup
> here.]
> 
> Do you have any thoughts on why I might be getting incorrect default
> behaviour?  Where might I look to try to track down what's going on?

The value of normal-erase-is-backspace is the place to start: if your
system has both a Backspace key and a Delete key, Emacs should have
set normal-erase-is-backspace to t.  This setting happens in
startup.el: Emacs invokes the function x-backup-delete-keys-p, and if
it returns non-nil, assumes both Backspace and Delete keys exist and
are bound to their usual meanings.

The function x-backup-delete-keys-p (defined on xfns.c) needs the XKB
extension of the X libraries to do its work; if your system doesn't
support XKB, that could be the reason why the above automagic doesn't
work.

I hope the information above gives you enough to start tracing what
happens on your system during startup and see why Emacs doesn't DTRT.

Re: inconsistent bindings of backspace and delete between X and xterm

[Dale Hagglund]

Eli Zaretskii <eliz@elta.co.il> writes:

> The function x-backup-delete-keys-p (defined on xfns.c) needs the XKB
> extension of the X libraries to do its work; if your system doesn't
> support XKB, that could be the reason why the above automagic doesn't
> work.

Bingo! x-backspace-delete-keys-p returns nil.  As I mentioned, I'm
running emacs inside a vnc server session, and vnc's virtual X server
does *not* support the XKEYBOARD extension.  I also just checked my
emacs at home, which is running under a native X server, and it does
have normal-erase-is-backspace set to t.

> I hope the information above gives you enough to start tracing what
> happens on your system during startup and see why Emacs doesn't
> DTRT.

Yep.  Thanks for the info.

Dale.