From: Kai.Grossjohann@CS.Uni-Dortmund.DE
Subject: Re: B [backspace] should act like B [delete]?
Date: 14 Jun 1999 23:49:33 +0200 [thread overview]
Message-ID: <vafogii5u6q.fsf@petty.cs.uni-dortmund.de> (raw)
In-Reply-To: Karl Kleinpaste's message of "14 Jun 1999 12:23:07 -0400"
Karl Kleinpaste <karl@justresearch.com> writes:
> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> > Normally, <backspace> and <delete> both generate DEL, and DEL (\177)
> > is bound. Binding <backspace> or <delete> overrides that generation
> > of DEL.
>
> No, not so.
In what way is my explanation wrong? I think saying "emacs-20.3 -q
-no-site-file" then hitting C-h c <backspace> and C-h c <delete> will
show you that I was right.
Hm.
Maybe I should have said `by default' instead of `normally'...
> Under X, the key labelled "<-" generates keysym Backspace and the one
> labelled "Del" generates keysym Delete. XEmacs knows the difference,
> annoyingly. Experiment with xev(1), and you'll see what I mean. If
> Emacs hides the distinction, it has done you a disservice.
I know about the keysyms. Emacs can also tell the difference. But
it's just that by default there is no difference. I think that
binding two keys to do the same thing by default is not a bad thing
per se. Cf. C-h and F1, or TAB and C-i, or RET and C-m, or even C-x
u and C-_.
> Having grown up on the VT100 (aka "God's") keyboard¹, I inverted the
> sense of these 2 keys on X keyboards for many, many years, because
> Delete Belongs At The Upper Right Of The Main Keyboard². The number
> of conflicts this causes, with applications which want to react to
> keysym Backspace but are blissfully unaware of Delete, has gotten
> large. So I finally gave in, tweaked my stty(1) invocation in
> .bash_login, undid the key inversion, and went in search of unexpected
> misbehavior with respect to Backspace and Delete.
>
> My hands still want desperately to type "B <-", which is why I'd like
> for the B summary submap to do -delete-article in that case.
Well, that's what you can do with the default setup of Gnus under
Emacs. The <backspace> key generates DEL, and B DEL is bound to
-delete-article, and Bob's your uncle. No problem there.
Btw, DEL is also bound to scroll-down (or something similar) in
view-mode, and since <backspace> generates DEL by default, the
intuitive keybinding works fine. On Emacs.
The fact that <delete> *also* does all of this is of little impact to
the <backspace> key. The default behavior that <delete> also
generates DEL should be turned off. But why turn off the <backspace>
behavior, too? The key already does the right thing.
> Generally speaking, Backspace and Delete both do deletion-related
> things, so it seemed to be a sensible suggestion.
Well, I don't really know how XEmacs handles all this. I vaguely
remember that it works differently there. But I don't recall any
details. I hope I have explained in sufficient detail what I think
should be done in Emacs. But let me say it again:
- Default Emacs behavior:
<backspace> and <delete> generate DEL, and all keybindings refer
to DEL, neither to <backspace> nor to <delete>.
- Kai's suggested Emacs behavior:
<backspace> generates DEL, all keybindings refer to DEL.
<delete> is rebound to delete-char in most modes.
As you can see, my suggestion means that all existing DEL bindings
continue to be used, and the <backspace> key retains the `delete in a
backward direction' meaning it used to have all along. (By this I
mean that the key in that position used to have that meaning, though
that key used to be called DEL and not <backspace>.)
> ¹ I have a VT102 of my very own. Really.
> ² Under X, I *still* invert the placement of the `~ and ESC keys -- I
> even switch their keycaps -- because Escape Belongs At The Upper
> Left Of The Main Keyboard. :-)
He, at work I've got a Sun type 5 kbd, and there the ESC key is to the
left of the 1 -- that's what you're talking about, right? I admit
that I also get along with the default PC kbd placement of ESC.
PS: I tried to consistently use different spelling: <backspace> and
<delete> refer to keys on the kbd, and DEL and ESC and RET refer
to names of ASCII characters. After all, you can type C-[ to get
ESC, too.
kai
--
Abort this operation? [OK] [Cancel]
next prev parent reply other threads:[~1999-06-14 21:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-06-14 15:27 Karl Kleinpaste
1999-06-14 16:03 ` Kai.Grossjohann
1999-06-14 16:23 ` Karl Kleinpaste
1999-06-14 21:49 ` Kai.Grossjohann [this message]
1999-06-14 17:07 ` Harry Putnam
1999-06-14 21:51 ` Kai.Grossjohann
1999-06-14 17:55 ` Hrvoje Niksic
1999-06-14 21:57 ` Kai.Grossjohann
1999-06-15 0:44 ` Karl Kleinpaste
1999-06-15 15:33 ` Hrvoje Niksic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vafogii5u6q.fsf@petty.cs.uni-dortmund.de \
--to=kai.grossjohann@cs.uni-dortmund.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).