emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: S-backspace


From: Richard Stallman
Subject: Re: S-backspace
Date: Fri, 30 May 2003 13:12:22 -0400

    The binding itself is clearly not dangerous, once Emacs even gets to
    see the binding the danger is over.  The danger consists in
    encouraging people to use it without properly warning them.

That is true.  But there are Emacs help commands that will display
the binding and won't display any additional information.
For instance, C-h w backward-kill-sexp says

    backward-kill-sexp is on <C-M-backspace>, <C-M-delete>, ESC <C-backspace>, 
ESC <C-delete>

C-M-backspace seems to be a danger under XFree86, and you've said that
C-M-delete might also be one with some window managers (though not
with mine).  Meanwhile, C-M-delete causes a reboot on the console,
but C-M-backspace doesn't.

    It doesn't matter anyways, because it is part of the structure of the
    commands that move around sexprs. The first time I killed my X-Server
    I simply wanted to 'kill the s-expression before point'. I didn't
    read in the documentation that this command exists and that it is
    bound to `C-M-<backspace>'; it's just the logical binding when you
    are familiar with `M-C-a', `M-C-f' etc.

I guess nothing we might do can close that pitfall.  But in addition
to people who deduce this command ought to exist, there must be others
who read about it.

Since this command is not often used, I think the danger exceeds the
utility.  I am coming to think that the best thing to do is to delete
both bindings, and let real Emacs wizards who want a key binding for
this command make one themselves.


All in all, the situation created by XFree86 and Linux is a confusing
one.  Given that XFree86 turns off the Linux handling of C-M-delete as
a command to reboot, shouldn't it use C-M-delete for killing the X
server, rather than C-M-backspace?  That way, one key would be used by
the system for two similar purposes depending on the situation, and
the other key would always be available for other programs.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]