Bug 10648 - backspace/delete issues with emacs under X
backspace/delete issues with emacs under X
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-07 15:41 EDT by Red Hat Bugzilla
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-04-10 11:59:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2000-04-07 15:41:47 EDT
Package: emacs-20.5-7
File: /usr/share/emacs/20.5/lisp/term/x-win.elc

Under X, both backspace and delete are mapped to keycode 127.  Hence, both
will delete the character immediately before the cursor.  This is the
expected behavior for backspace, but for delete, it should delete the
character in front of the cursor.

The solution is to change the file from:
... [backspace] [127] [delete] [127] [tab] [9] ...
to:
... [backspace] [127] [delete] [deletechar] [tab] [9] ...

This is on line 44 of the file.

(I believe that this is not the original source for this file, so the
proper fix is to change it elsewhere and regenerate this file)
Comment 1 Red Hat Bugzilla 2000-04-10 11:59:59 EDT
No need to do that - just add this

(global-set-key [delete] 'delete-char)

to your .emacs. I think I'll add it to the global one, too.
Comment 2 Red Hat Bugzilla 2000-04-10 12:14:59 EDT
Actually, we already do that in the default $HOME/.emacs in 6.2
Comment 3 Red Hat Bugzilla 2000-04-10 12:22:59 EDT
I wouldn't rely on the configuation of ~/.emacs; it isn't always set up by Red
Hat (or even any Linux distribution for that matter).  In my case, user
directories are NFS mounted, based on a Solaris setup.  This is probably not
terribly unusual in the corporate world.  As long as it works with any ~/.emacs
(or even with no ~/.emacs), then there's no problem (regardless of which of the
Eighty Million Alternate Configuration Strategies you choose).

Note You need to log in before you can comment on or make changes to this bug.