From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
"'Paul Griepentrog'" <pgriepen@gmail.com>
Cc: 'Adrian Robert' <adrian.b.robert@gmail.com>, 6616@debbugs.gnu.org
Subject: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 1 Aug 2010 18:57:50 -0700 [thread overview]
Message-ID: <4CD0D87139BC44498B99843347AF787B@us.oracle.com> (raw)
In-Reply-To: <jwv39ux7uhs.fsf-monnier+emacs@gnu.org>
> > I say, pick a solution and make it consistent across the modes
> > shipped with Emacs. IMHO, [S-tab] is the 'correct' binding,
> > since we press those actual keys.
>
> In most cases I've seen `backtab' is the "correct" binding
> because it's
> the one that makes logical sense: the command is about doing something
> in the opposite direction from what the `tab' key does.
> The reason why S-tab is (also) used is that `backtab' is rarely
> available, and as a convention we use S-tab as a poor man's backtab.
Hm. Then perhaps I do disagree. I thought that I had misunderstood and this was
not, after all, about binding the S-tab or backtab key to any given command by
default, but it was just about linking S-tab to backtab (both being keys).
I would oppose binding either key to some command everywhere, "fallback" or not.
As soon as that happens we will get people who complain if a 3rd-party library
binds S-tab, even optionally or via an initialization command.
S-tab and backtab keys can be linked to each other by default for convenience,
but they should both be free of any command by default - except in particular
contexts (e.g. *Help*, Info).
BTW, there are not only the S-tab and backtab keys that should (perhaps) be
linked together by default, but also the S-iso-tab key. Typically, when code
binds S-tab it also needs to bind S-iso-tab. At least in some cases, we have
already taken care of that via backtab, IIRC.
next prev parent reply other threads:[~2010-08-02 1:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-12 6:20 bug#6616: S-TAB is mismapped in the *Help* buffer Paul Griepentrog
2010-07-12 17:29 ` Eli Zaretskii
2010-07-12 19:03 ` Adrian Robert
2010-07-12 19:10 ` Eli Zaretskii
2010-07-13 5:42 ` Paul Griepentrog
2010-07-13 7:28 ` Adrian Robert
2010-07-13 9:50 ` Eli Zaretskii
2010-07-13 9:49 ` Eli Zaretskii
2010-08-01 0:04 ` Stefan Monnier
2010-08-01 14:24 ` Drew Adams
2010-08-01 18:59 ` Drew Adams
2010-08-01 23:32 ` Stefan Monnier
2010-08-02 1:51 ` Drew Adams
2010-08-01 17:38 ` Paul Griepentrog
2010-08-02 0:03 ` Stefan Monnier
2010-08-02 1:57 ` Drew Adams [this message]
2010-08-02 8:22 ` Stefan Monnier
2010-08-02 4:30 ` Paul Griepentrog
2010-07-13 10:47 ` bug#6616: Closing, checked fix in to trunk r100808 Adrian Robert
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD0D87139BC44498B99843347AF787B@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=6616@debbugs.gnu.org \
--cc=adrian.b.robert@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=pgriepen@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).