Bug 81947 - control-alt-backspace is not available to Emacs
Summary: control-alt-backspace is not available to Emacs
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Whiteboard: Waiting for information from upstream...
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-15 17:27 UTC by Sam Steingold
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-24 13:59:42 UTC

Attachments (Terms of Use)

Description Sam Steingold 2003-01-15 17:27:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218

Description of problem:
control-alt-backspace (C-M-BS) is an important key combination in Emacs,
usually bound to kill-sexp-backwards.
in phoebe, it is not available to Emacs.

Version-Release number of selected component (if applicable): 

How reproducible:

Steps to Reproduce:
1.start X
2.start Emacs
3.type "foo"
4.type Ctrl-Alt-BS

Actual Results:  nothing happens

Expected Results:  "foo" should be deleted

Additional info:

1. to see that this key combo is not passed to emacs, type 
      C-h c 
   (describe key) and then C-M-BS - nothing appears in the echo area.
   if you type any other key instead, e.g., C-h c C-h a, emacs will
   tell you that C-h a runs apropos-command.

2. usually, C-M-BS kills the X server, so you need to enable the
   DontZap option in /etc/X11/XF86Config.

3. xev(1) reports C-M-BS as

KeyPress event, serial 25, synthetic NO, window 0x2c00001,
    root 0x3f, subw 0x0, time 65848720, (154,149), root:(162,184),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:  ""

KeyPress event, serial 25, synthetic NO, window 0x2c00001,
    root 0x3f, subw 0x0, time 65848733, (154,149), root:(162,184),
    state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:  ""

KeyRelease event, serial 25, synthetic NO, window 0x2c00001,
    root 0x3f, subw 0x0, time 65849308, (154,149), root:(162,184),
    state 0xc, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:  ""

some files in /etc/X11/xkb/symbols/ mention "Terminate_Server".

this is extremely inconvenient.

Comment 1 Mike A. Harris 2003-01-23 11:56:53 UTC
Please report this problem upstream to XFree86.org's bug report and
general purpose email list address: xfree86@xfree86.org

The 4.3.0 release is nearing, and few people understand the new xkb
infrastructure.  I'm unfortunately not one of them.  Ivan Pascal, and
others working on xkb however should be made aware of these types of
issues, so they can fix them if necessary before the 4.3.0 release, of
which freeze occurs on Feb 1st.

I'm keeping this bug open to monitor upstream changes, and discussions.
I'll update the report once a fix is checked into CVS upstream and
incorporated into my packages.

Thanks in advance.

Comment 2 Sam Steingold 2003-01-23 16:19:42 UTC
I did send an e-mail you indicated.
in the meantime, uncommenting 
   "keycode 22 = BackSpace" 
in /etc/X11/Xmodmap should fix the problem.

Comment 3 Mike A. Harris 2003-01-24 13:59:42 UTC
We don't accept bug reports nor bug report information updates via email.
Email is untrackable, and disassociates the email from the problem.

I delete emailed bug reports on site unread.

Hacking Xmodmap is an unacceptable solution to ship the OS with.

This alleged problem is something that needs to be fixed or worked out
between you and XFree86.org as I'm not making changes for what I consider
to be a 1 user in 10000000 hack that could jeopardize setups of multitudes
of other users, and have it called a "Red Hat Hack" by the community.

I'm closing this as WONTFIX.  If XFree86 checks some kind of change into
CVS that is considered acceptable by them, then it will make it into our
OS.  If they don't consider it a problem, or don't consider any solution,
then I'm hard pressed myself to consider this a problem.  Inside XFree86,
the CTRL-ALT-BS keystroke has a very definite meaning.  Any app relying
on being able to use that keystroke, is IMHO broken itself.

User interface consistency trumps hacks-for-emacs-oddball-keybindings.

Comment 4 Sam Steingold 2003-01-24 18:28:36 UTC
your rudeness is incomprehensible to me.

the Emacs users far outnumber redhat users (especically among the people who
contribute to Linux development).
Emacs predates X.
you asked me to send e-mail to xfree86@xfree86.org yourself.

Comment 5 Mike A. Harris 2003-01-24 20:22:27 UTC
Sorry, I'm not being rude, I'm being blatantly honest.  The issue reported
here has been reported by one single person out of all Red Hat Linux users
so far.

The number of bugs in our bug queue right now is high enough and to
prioritize investigation of this issue personally, by me, the sole X
developer working on the base OS here, when the XFree86 community can
do this themselves, is pushing this trivial issue up the stack, and 
shutting out users who can't even start up their X server.

Low priority and trivial issues will either sit in the queue indefinitely
and never get looked at, or we can tell people to report them upstream,
where they _will_ get looked at, and get fixed too.  Experience in the
last month of bouncing xkb issues upstream has resulted in about an 80%
rate of xkb bugs being fixed within 2-3 days if not 6 hours of being

The entire open source community using XFree86 deserves these fixes, not
just Red Hat.  And Red Hat is not in the best position to fix these types
of bugs, or to judge wether a fix is correct or not.

XFree86.org is.  Due to bug queue right now, I am defering all xkb and
similar issues to XFree86.org to resolve.

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