GNU bug report logs - #2057
23.0.60; delete key and deletechar

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2057 in the body.
You can then email your comments to 2057 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <robert.brown <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; delete key and deletechar
Date: Sun, 25 Jan 2009 18:01:26 -0500

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I start Emacs 23.0.60.2 on Ubuntu 8.10 inside a gnome-terminal emulation
window using the command "emacs -q -nw".  The backspace key on my keyboard is
set up to generate ASCII code 127, but Emacs incorrectly maps this code to
deletechar with input-decode-map which is:

    (keymap (127 . [deletechar]) (27 keymap (79 keymap (83 . ....

I believe this input translation is set up by term_get_fkeys_1 in term.c when
it looks at the termcap/terminfo function key definitions for my terminal
type, xterm-color, and sees that the termcap description contains:

    kD=\177

which means that the delete *function* key produces ASCII code 127.

Emacs should look at both kD and kb.  If they are the same ASCII character,
then Emacs should not install a translation in input-decode-map for delete.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/local/software/package/emacs-23.0.60.2/share/emacs/23.0.60/etc/DEBUG
for instructions.


In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu)
 of 2009-01-18 on ugg
configured using `configure  '--without-x'
'--prefix=/local/software/package/emacs-23.0.60.2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  savehist-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 1 ; 1 7 0 4 ; 0 c C-h i m e m a c s RET C-s
b u g SPC C-a C-n C-f C-f C-f C-f C-f C-f RET SPC SPC
ESC x r e p o r t - e m a c s - b u g RET

Recent messages:
("emacs")
Composing main Info directory...done
Mark saved where search started

Message #10 received at 2057 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <brown <at> google.com>
To: 2057 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 11:10:13 -0400

I believe the following patch may be the right fix for bug 2057.  When
looking at the key sequences generated by function keys, Emacs should only
register those that generate two or more ASCII characters.

My termcap entry, xterm-color, contains "kD=\177", which means that the
delete *function* key generates code 177.

The function key mapping code in term.c incorrectly creates a translation
that maps charcter code 177 to deletechar.  The translation is incorrect
because the normal backspace/delete key on my keyboard also generates code
177.  Once the translation is set up, hitting backspace/delete causes Emacs
to delete characters to the right instead of to the left, since Emacs thinks
I'm hitting the delete *function* key.

bob

====================


--- src/term.c.~1~      2009-04-13 14:57:19.000000000 -0400
+++ src/term.c  2009-04-16 10:59:32.000000000 -0400
@@ -1410,7 +1410,7 @@
   for (i = 0; i < (sizeof (keys)/sizeof (keys[0])); i++)
     {
       char *sequence = tgetstr (keys[i].cap, address);
-      if (sequence)
+      if (sequence && strlen(sequence) > 1)
        Fdefine_key (kboard->Vinput_decode_map, build_string (sequence),
                     Fmake_vector (make_number (1),
                                   intern (keys[i].name)));

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <brown <at> google.com>
To: 2057 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 11:33:21 -0400

On second thought, maybe the real bug is with the termcap entry.  Hitting
the function key labeled delete on my keyboard generates:

   escape [ 3 ~

not character 177.  Maybe function keys always generate multi-character
sequences, so there's generally no confusion between the function key and a
normal key.

bob

====================


--- src/term.c.~1~      2009-04-13 14:57:19.000000000 -0400
+++ src/term.c  2009-04-16 10:59:32.000000000 -0400
@@ -1410,7 +1410,7 @@
   for (i = 0; i < (sizeof (keys)/sizeof (keys[0])); i++)
     {
       char *sequence = tgetstr (keys[i].cap, address);
-      if (sequence)
+      if (sequence && strlen(sequence) > 1)
        Fdefine_key (kboard->Vinput_decode_map, build_string (sequence),
                     Fmake_vector (make_number (1),
                                   intern (keys[i].name)));

Message #28 received at 2057 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Robert Brown <brown <at> google.com>
Cc: 2057 <at> debbugs.gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 09:19:55 -0700 (PDT)

Robert Brown <brown <at> google.com> writes:

  > I believe the following patch may be the right fix for bug 2057.  When
  > looking at the key sequences generated by function keys, Emacs should only
  > register those that generate two or more ASCII characters.
  > 
  > My termcap entry, xterm-color, contains "kD=\177", which means that the
  > delete *function* key generates code 177.

Interesting, it seems that you have a modified termcap database, the normal one
has kD=\E[3~ for xterm-color.

What you are seeing is probably the effect of what
`normal-erase-is-backspace' does. 

Can you try setting TERM to xterm-256color and see if that the delete
key works better then?  (It's quite likely that nowadays terminal
emulators are compiled with 256 color support)

Message #33 received at 2057 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <brown <at> google.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 2057 <at> debbugs.gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 13:54:28 -0400

Dan Nicolaescu writes:
 > Robert Brown <brown <at> google.com> writes:
 > 
 >   > I believe the following patch may be the right fix for bug 2057.  When
 >   > looking at the key sequences generated by function keys, Emacs should only
 >   > register those that generate two or more ASCII characters.
 >   > 
 >   > My termcap entry, xterm-color, contains "kD=\177", which means that the
 >   > delete *function* key generates code 177.
 > 
 > Interesting, it seems that you have a modified termcap database, the normal one
 > has kD=\E[3~ for xterm-color.

Yes, it's definitely a bug in the termcap entry.  Hitting the delete
function key generates \E[3~ for me.  I can fix the termcap.

 > Can you try setting TERM to xterm-256color and see if that the delete
 > key works better then?

Switching to a different termcap works well.

I still think it may incorrect for Emacs to map single character function
key sequences.  But perhaps these just never occur in practice.

bob

Message #38 received at 2057-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Robert Brown <brown <at> google.com>
Cc: 2057-done <at> debbugs.gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 11:17:48 -0700 (PDT)

Robert Brown <brown <at> google.com> writes:

  > Dan Nicolaescu writes:
  >  > Robert Brown <brown <at> google.com> writes:
  >  > 
  >  >   > I believe the following patch may be the right fix for bug 2057.  When
  >  >   > looking at the key sequences generated by function keys, Emacs should only
  >  >   > register those that generate two or more ASCII characters.
  >  >   > 
  >  >   > My termcap entry, xterm-color, contains "kD=\177", which means that the
  >  >   > delete *function* key generates code 177.
  >  > 
  >  > Interesting, it seems that you have a modified termcap database, the normal one
  >  > has kD=\E[3~ for xterm-color.
  > 
  > Yes, it's definitely a bug in the termcap entry.  Hitting the delete
  > function key generates \E[3~ for me.  I can fix the termcap.
  > 
  >  > Can you try setting TERM to xterm-256color and see if that the delete
  >  > key works better then?
  > 
  > Switching to a different termcap works well.

OK, so it's not an emacs bug, closing this then.

  > I still think it may incorrect for Emacs to map single character function
  > key sequences.  But perhaps these just never occur in practice.

Given that we don't have a positive proof that it causes a problem,
there doesn't seem to be a good reason to change code that has been
around for such a long time.

Message #43 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Robert Brown <brown <at> google.com>
Cc: 2057 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 14:45:54 -0400

> My termcap entry, xterm-color, contains "kD=\177", which means that the
> delete *function* key generates code 177.

Why does the termcap data have such an entry for kD?  That looks like a bug.
Does it also have a similar entry for the backspace key?


        Stefan

Message #53 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <brown <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2057 <at> debbugs.gnu.org.emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Thu, 16 Apr 2009 14:54:36 -0400

Stefan Monnier writes:
 > > My termcap entry, xterm-color, contains "kD=\177", which means that the
 > > delete *function* key generates code 177.
 > 
 > Why does the termcap data have such an entry for kD?  That looks like a bug.
 > Does it also have a similar entry for the backspace key?

It's definitely a bug in the termcap entry.  The odd thing is what happened
afterward.  Emacs created an input mapping that converts 177 into
deletechar, messing up the action of the normal delete/backspace key.

There's an assumption that function keys never generate a single character
that's the same as some normal key.  Or alternatively, function keys take
precedence over normal keys if there's any overlap in generated codes.

bob

Message #59 received at 2057-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Robert Brown <brown <at> google.com>
Cc: 2057-done <at> debbugs.gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Fri, 17 Apr 2009 16:19:00 -0400

> I still think it may incorrect for Emacs to map single character function
> key sequences.  But perhaps these just never occur in practice.

I do agree that your patch seems reasonable.  But there might be
terminals where function keys send non-ASCII single byte codes in which
case your patch would be incorrect.  Now I don't know whether such
terminals are more or less rare than those who send ASCII codes for
function keys.  So at least, for the purpose of the current pretest, I'd
rather keep the old behavior (that's been around for many years) rather
than risk breaking some oddball system out there.  Especially since your
particular problem really turned out to be a bug in the termcap.


        Stefan

Message #60 received at 2057-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Robert Brown <brown <at> google.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 2057-done <at> debbugs.gnu.org
Subject: Re: bug#2057: 23.0.60; delete key and deletechar
Date: Fri, 17 Apr 2009 16:33:44 -0400

Stefan Monnier writes:
 > > I still think it may incorrect for Emacs to map single character function
 > > key sequences.  But perhaps these just never occur in practice.
 > 
 > I do agree that your patch seems reasonable.  But there might be
 > terminals where function keys send non-ASCII single byte codes in which
 > case your patch would be incorrect.  Now I don't know whether such
 > terminals are more or less rare than those who send ASCII codes for
 > function keys.  So at least, for the purpose of the current pretest, I'd
 > rather keep the old behavior (that's been around for many years) rather
 > than risk breaking some oddball system out there.  Especially since your
 > particular problem really turned out to be a bug in the termcap.

I agree.  Better to leave everything as it is.  Thanks very much for taking
a look.

bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.