Bug 10648

Summary: backspace/delete issues with emacs under X
Product: [Retired] Red Hat Linux Reporter: Red Hat Bugzilla <bugzilla>
Component: emacsAssignee: Cristian Gafton <gafton>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: dr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-04-10 15:59:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Red Hat Bugzilla 2000-04-07 19:41:47 UTC 
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 15:59:59 UTC 
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 16:14:59 UTC 
Actually, we already do that in the default $HOME/.emacs in 6.2
Comment 3 Red Hat Bugzilla 2000-04-10 16:22:59 UTC 
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).