Gnus development mailing list
 help / color / mirror / Atom feed
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]


  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).