GNU bug report logs - #6616
S-TAB is mismapped in the *Help* buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6616 in the body.
You can then email your comments to 6616 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Griepentrog <pgriepen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: S-TAB is mismapped in the *Help* buffer
Date: Sun, 11 Jul 2010 23:20:22 -0700

 The manual, (info "(emacs) Help Mode"), says "S-TAB"
moves the point to the previous cross reference when in
the *Help* buffer.  But, trying from a default emacs
shows "S-TAB" is translated to "C-y":

    emacs -Q
      ...                 ; Get to a *Help* buffer
    C-h k S-TAB

    C-y (translated from <S-tab>) runs the command yank, which is an
    interactive compiled Lisp function in `simple.el'.

My guess is that the right place to change this is
in the `button-buffer-map'.  This way the change will
propagate to other modes that use button-buffer-map as
a parent keymap, including:

    apropos.el          ; apropos-mode-map
    emacs-lisp/debug.el ; debugger-mode-map
    help-mode.el        ; help-mode-map (this bug)
    man.el              ; Man-mode-map
    progmodes/etags.el  ; select-tags-table-mode-map
    startup.el          ; splash-screen-keymap


diff --git a/lisp/button.el b/lisp/button.el
index 2a9a49c..ad4613d 100644
--- a/lisp/button.el
+++ b/lisp/button.el
@@ -73,6 +73,7 @@
     (define-key map [?\t] 'forward-button)
     (define-key map "\e\t" 'backward-button)
     (define-key map [backtab] 'backward-button)
+    (define-key map [S-tab] 'backward-button)
     map)
   "Keymap useful for buffers containing buttons.
 Mode-specific keymaps may want to use this as their parent keymap.")

In GNU Emacs 24.0.50.3 (i686-apple-darwin10.6.4, NS apple-appkit-1038.32)
of 2010-07-10 on walnut.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure '--build' 'i686-apple-darwin10.6.4' 
'--without-dbus' '--with-ns' 'build_alias=i686-apple-darwin10.6.4' 
'CC=gcc -I/usr/include -L/usr/lib' 'CFLAGS=-pipe -arch i386 -gdwarf-2 
-g3' 'LDFLAGS=-arch i386''

Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
autopair-mode: t
autopair-global-mode: t
yas/global-mode: t
otherwindow-marker-mode: t
window-number-meta-mode: t
shell-dirtrack-mode: t
recentf-mode: t
ido-everywhere: t
show-paren-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t

Recent input:
C-c C-g s e t SPC c u <return> o r a n g e <return>
C-c 0 C-x C-f <return> p <return> t a b C-s <return>
C-c C-g b u g SPC SPC SPC <M-backspace> <M-backspace>
f i l e SPC b <M-backspace> b u <tab> <backspace> <tab>
C-g C-c C-g b u g <tab> <M-backspace> <M-backspace>
r e p o r SPC b <tab> <return>

Recent messages:
Loading ~/.emacs.d/paul/pg-config...
Ido mode enabled
Loading /Users/pgriepen/.emacs.d/recentf.dat...done
Cleaning up the recentf list...done (0 removed)
Loading ~/.emacs.d/paul/pg-config...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-git...done
Making completion list...
Quit

Load-path shadows:
~/Local/share/emacs/site-lisp/autopair hides ~/.emacs.d/packages/autopair
~/.emacs.d/packages/linum hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/linum
~/.emacs.d/packages/remember hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/textmodes/remember
~/.emacs.d/packages/css-mode hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/textmodes/css-mode
~/.emacs.d/packages/ruby-mode hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/progmodes/ruby-mode
~/Local/share/emacs/site-lisp/org hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org
~/Local/share/emacs/site-lisp/org-xoxo hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-xoxo
~/Local/share/emacs/site-lisp/org-wl hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-wl
~/Local/share/emacs/site-lisp/org-w3m hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-w3m
~/Local/share/emacs/site-lisp/org-vm hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-vm
~/Local/share/emacs/site-lisp/org-timer hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-timer
~/Local/share/emacs/site-lisp/org-table hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-table
~/Local/share/emacs/site-lisp/org-src hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-src
~/Local/share/emacs/site-lisp/org-rmail hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-rmail
~/Local/share/emacs/site-lisp/org-remember hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-remember
~/Local/share/emacs/site-lisp/org-publish hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-publish
~/Local/share/emacs/site-lisp/org-protocol hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-protocol
~/Local/share/emacs/site-lisp/org-plot hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-plot
~/Local/share/emacs/site-lisp/org-mouse hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-mouse
~/Local/share/emacs/site-lisp/org-mobile hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-mobile
~/Local/share/emacs/site-lisp/org-mhe hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-mhe
~/Local/share/emacs/site-lisp/org-mew hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-mew
~/Local/share/emacs/site-lisp/org-macs hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-macs
~/Local/share/emacs/site-lisp/org-mac-message hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-mac-message
~/Local/share/emacs/site-lisp/org-list hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-list
~/Local/share/emacs/site-lisp/org-latex hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-latex
~/Local/share/emacs/site-lisp/org-jsinfo hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-jsinfo
~/Local/share/emacs/site-lisp/org-irc hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-irc
~/Local/share/emacs/site-lisp/org-install hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-install
~/Local/share/emacs/site-lisp/org-inlinetask hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-inlinetask
~/Local/share/emacs/site-lisp/org-info hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-info
~/Local/share/emacs/site-lisp/org-indent hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-indent
~/Local/share/emacs/site-lisp/org-id hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-id
~/Local/share/emacs/site-lisp/org-icalendar hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-icalendar
~/Local/share/emacs/site-lisp/org-html hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-html
~/Local/share/emacs/site-lisp/org-habit hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-habit
~/Local/share/emacs/site-lisp/org-gnus hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-gnus
~/Local/share/emacs/site-lisp/org-freemind hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-freemind
~/Local/share/emacs/site-lisp/org-footnote hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-footnote
~/Local/share/emacs/site-lisp/org-feed hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-feed
~/Local/share/emacs/site-lisp/org-faces hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-faces
~/Local/share/emacs/site-lisp/org-exp hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-exp
~/Local/share/emacs/site-lisp/org-exp-blocks hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-exp-blocks
~/Local/share/emacs/site-lisp/org-entities hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-entities
~/Local/share/emacs/site-lisp/org-docview hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-docview
~/Local/share/emacs/site-lisp/org-docbook hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-docbook
~/Local/share/emacs/site-lisp/org-datetree hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-datetree
~/Local/share/emacs/site-lisp/org-ctags hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-ctags
~/Local/share/emacs/site-lisp/org-crypt hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-crypt
~/Local/share/emacs/site-lisp/org-compat hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-compat
~/Local/share/emacs/site-lisp/org-colview hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-colview
~/Local/share/emacs/site-lisp/org-clock hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-clock
~/Local/share/emacs/site-lisp/org-bibtex hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-bibtex
~/Local/share/emacs/site-lisp/org-beamer hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-beamer
~/Local/share/emacs/site-lisp/org-bbdb hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-bbdb
~/Local/share/emacs/site-lisp/org-attach hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-attach
~/Local/share/emacs/site-lisp/org-ascii hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-ascii
~/Local/share/emacs/site-lisp/org-archive hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-archive
~/Local/share/emacs/site-lisp/org-agenda hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/org/org-agenda
~/Local/share/emacs/site-lisp/trampver hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/trampver
~/Local/share/emacs/site-lisp/tramp hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp
~/Local/share/emacs/site-lisp/tramp-uu hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-uu
~/Local/share/emacs/site-lisp/tramp-smb hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-smb
~/Local/share/emacs/site-lisp/tramp-gw hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-gw
~/Local/share/emacs/site-lisp/tramp-ftp hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-ftp
~/Local/share/emacs/site-lisp/tramp-fish hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-fish
~/Local/share/emacs/site-lisp/tramp-compat hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-compat
~/Local/share/emacs/site-lisp/tramp-cmds hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-cmds
~/Local/share/emacs/site-lisp/tramp-cache hides 
/Applications/Emacs-24.app/Contents/Resources/lisp/net/tramp-cache

Features:
(shadow sort mail-extr message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug help-mode
view vc-git paredit server package remember org-install org byte-opt
warnings bytecomp byte-compile org-footnote org-src org-list org-faces
org-compat org-entities org-macs time-date noutline outline cal-menu
calendar cal-loaddefs xcscope xgtags autopair yasnippet-config yasnippet
dropdown-list derived easy-mmode edmacro kmacro assoc ibuf-ext ibuffer
wn-org nav nav-tags python-21 python imenu nav-bufs dired-details dired+
dired-x ediff-merg ediff-diff ediff-wind ediff-mult ediff-help
ediff-init ediff-util dired-aux dired otherwindow-marker window-number
saveplace tramp-gw tramp-fish tramp-smb tramp-cache tramp-ftp tramp-cmds
tramp auth-source gnus-util shell comint password-cache format-spec
tramp-compat trampver recentf tree-widget wid-edit browse-kill-ring ido
bbdb-autoloads bbdb regexp-opt timezone otp winner ring avoid paren
uniquify advice help-fns advice-preload cl cl-19 tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)

Message #8 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Griepentrog <pgriepen <at> gmail.com>,
	Adrian Robert <Adrian.B.Robert <at> gmail.com>
Cc: 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 12 Jul 2010 20:29:53 +0300

> Date: Sun, 11 Jul 2010 23:20:22 -0700
> From: Paul Griepentrog <pgriepen <at> gmail.com>
> Cc: 
> 
>   The manual, (info "(emacs) Help Mode"), says "S-TAB"
> moves the point to the previous cross reference when in
> the *Help* buffer.  But, trying from a default emacs
> shows "S-TAB" is translated to "C-y":
> 
>      emacs -Q
>        ...                 ; Get to a *Help* buffer
>      C-h k S-TAB
> 
>      C-y (translated from <S-tab>) runs the command yank, which is an
>      interactive compiled Lisp function in `simple.el'.

This is Mac-specific, and it is due to this line from term/ns-win.el:

    (define-key map [S-tab] [25])

I have no idea why this line is there, perhaps Mac users expect this
binding.  I also don't see how this line plays with the following line
from the same ns-win.el, a few lines up:

    (put 'S-tab 'ascii-character (logior 16 ?\t))

These two lines have been there for almost 2 years.

> My guess is that the right place to change this is in the
> `button-buffer-map'.

No, the right way seems to be to find out why ns-win.el defines this
strange mapping.  Adrian?

Message #11 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Griepentrog <pgriepen <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 12 Jul 2010 22:03:11 +0300

On Jul 12, 2010, at 8:29 PM, Eli Zaretskii wrote:

> This is Mac-specific, and it is due to this line from term/ns-win.el:
> 
>    (define-key map [S-tab] [25])
> 
> I have no idea why this line is there, perhaps Mac users expect this
> binding.  I also don't see how this line plays with the following line
> from the same ns-win.el, a few lines up:
> 
>    (put 'S-tab 'ascii-character (logior 16 ?\t))
> 
> These two lines have been there for almost 2 years.
> 
>> My guess is that the right place to change this is in the
>> `button-buffer-map'.
> 
> No, the right way seems to be to find out why ns-win.el defines this
> strange mapping.  Adrian?


These lines were in the file when I started working with the port (more than 2 years ago ;), and although the definitions got moved around slightly, I never removed anything unless a problem was reported.  Now that we have this report, I propose removing BOTH of the S-tab lines.  I tried this locally and it did no harm, and let S-tab be interpreted (though some default mapping seems to translate it to plain tab).

The other stuff in ns-alternatives-map appears to be needed though, else the characters listed there don't get interpreted correctly.

Message #14 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: pgriepen <at> gmail.com, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 12 Jul 2010 22:10:06 +0300

> From: Adrian Robert <adrian.b.robert <at> gmail.com>
> Date: Mon, 12 Jul 2010 22:03:11 +0300
> Cc: Paul Griepentrog <pgriepen <at> gmail.com>,
>  6616 <at> debbugs.gnu.org
> 
> 
> These lines were in the file when I started working with the port (more than 2 years ago ;), and although the definitions got moved around slightly, I never removed anything unless a problem was reported.  Now that we have this report, I propose removing BOTH of the S-tab lines.  I tried this locally and it did no harm, and let S-tab be interpreted (though some default mapping seems to translate it to plain tab).

Sure, go ahead and remove these lines, and please close the bug after
you do.

Thanks.

Message #17 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Paul Griepentrog <pgriepen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 12 Jul 2010 22:42:14 -0700

 Thanks for looking into this.

On 7/12/10 12:10 PM, Eli Zaretskii wrote:
> > From: Adrian Robert <adrian.b.robert <at> gmail.com>
> > Date: Mon, 12 Jul 2010 22:03:11 +0300
> > Cc: Paul Griepentrog <pgriepen <at> gmail.com>,
> >  6616 <at> debbugs.gnu.org
> >
> >
> > These lines were in the file when I started working with the port (more
> > than 2 years ago ;), and although the definitions got moved around
> > slightly, I never removed anything unless a problem was reported.  
Now that
> > we have this report, I propose removing BOTH of the S-tab lines.  I tried
> > this locally and it did no harm, and let S-tab be interpreted (though 
some
> > default mapping seems to translate it to plain tab).

With the proposed change there still is no binding for backward-button in
*Help* and many other modes... the real problem.  The translation from S-TAB
to TAB effectively drops the shift modifier.

How about removing:

(put 'S-tab 'ascii-character (logior 16 ?\t))

and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?

    (define-key map [S-tab] [backtab])

Maybe stretching it here, but along this line of thinking, is it useful to
distinguish between [S-tab] and [backtab]?  Bug #1281 points out that it
becomes a hassle for users -- at least under Windows OS -- who must rebind
both [S-tab] and [backtab].

If it is not useful, we could remove the duplicate bindings which several
modes provide.  These modes often bind a combination of [S-tab], "\M-\t" or
"\e\t" to the same function invoked by [backtab]:
   - forms
   - info
   - widget
   - org-table
   - org
   - mh-letter
   - mh-folder
   - mh-show
   - info

Instead we could align it to other modes which only use [backtab]
   - erc
   - grep
   - compile
   - ses
   - diff-mode
   - log-view

Thanks for the consideration.

>  Sure, go ahead and remove these lines, and please close the bug after
>  you do.
>
>  Thanks.

Message #20 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Paul Griepentrog <pgriepen <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Tue, 13 Jul 2010 10:28:26 +0300

> With the proposed change there still is no binding for backward-button in
> *Help* and many other modes... the real problem.  The translation from S-TAB
> to TAB effectively drops the shift modifier.
> 
> ...
> 
> and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?

Not against this but I'd like to understand why it is needed.  All apps that I've seen treat shift-tab as different from tab, whether this is internally called "backtab" or whatever.  Can someone explain why the mapping S-tab -> tab is present in emacs?  Or is this resulting from something other issue specific to the NS port?

Message #23 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Griepentrog <pgriepen <at> gmail.com>
Cc: adrian.b.robert <at> gmail.com, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Tue, 13 Jul 2010 12:49:16 +0300

> Date: Mon, 12 Jul 2010 22:42:14 -0700
> From: Paul Griepentrog <pgriepen <at> gmail.com>
> CC: Adrian Robert <adrian.b.robert <at> gmail.com>, 6616 <at> debbugs.gnu.org
> 
>      (define-key map [S-tab] [backtab])

FWIW, w32-fns.el does this for MS-Windows.  Maybe ns-win.el should do
the same.

> Maybe stretching it here, but along this line of thinking, is it useful to
> distinguish between [S-tab] and [backtab]?

They are potentially two different keys, so I think they should be
distinguished.

> Bug #1281 points out that it becomes a hassle for users -- at least
> under Windows OS -- who must rebind both [S-tab] and [backtab].

That bug is about info.el, not about remapping S-tab.

Message #26 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: pgriepen <at> gmail.com, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Tue, 13 Jul 2010 12:50:50 +0300

> From: Adrian Robert <adrian.b.robert <at> gmail.com>
> Date: Tue, 13 Jul 2010 10:28:26 +0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  6616 <at> debbugs.gnu.org
> 
> Can someone explain why the mapping S-tab -> tab is present in
> emacs?

Perhaps because Emacs removes the Shift modifier if the shifted key is
unbound?

Message #31 received at 6616-done <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 6616-done <at> debbugs.gnu.org
Subject: Closing, checked fix in to trunk r100808
Date: Tue, 13 Jul 2010 13:47:24 +0300

S-tab is now translated to backtab as in w32.
Further debate on simplifying / lifting the handling of this generic key will take place on separate thread.

Message #34 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Griepentrog <pgriepen <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Adrian Robert <adrian.b.robert <at> gmail.com>,
	6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 01 Aug 2010 02:04:37 +0200

> and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?

Actually, we might want to do that everywhere, rather than only in
x-win.el and ns-win.el.


        Stefan

Message #37 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Paul Griepentrog'" <pgriepen <at> gmail.com>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: RE: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 1 Aug 2010 07:24:06 -0700

> > and binding [S-tab] to [backtab] in the 
> `ns-alternatives-map' instead?
> 
> Actually, we might want to do that everywhere, rather than only in
> x-win.el and ns-win.el.

I disagree.  S-TAB has always been a free global key, and it has remained free
in most keymaps.

In Emacs there are several different behaviors that here and there are
associated with TAB.  The use of TAB for navigation in the sense of being
opposite to [backtab] (e.g. navigation in Info or *Help*) is only one of them,
and it is a fairly minor one (for Emacs).  We only recently added it to Info.
Arguably it can be said to make sense for other, similar read-only modes such as
*Help*.  Beyond that it does not necessarily make sense.

Please do not bind S-TAB in a general way to [backtab] or anything else.  Modes
that really need that can do so.  That leaves other code (e.g. other modes, user
code, 3rd-party code) free to use S-TAB for other uses, especially uses that are
related to a particular use of TAB.  TAB for navigation is only one use of TAB.

We already have potential and some real conflicts between different meanings of
TAB.  A mode needs to choose which meaning it prefers when there is a potential
conflict.  Some modes try to combine such behaviors into a DWIM behavior.  This
is enough - let's not make this more problematic by throwing S-TAB into the mix
in a predefined way.  Let the code in question decide.

Bind S-TAB to `backtab' for *Help* if you want - that's helpful.  Likewise
perhaps some view-mode contexts (maybe all of them; dunno).  But otherwise
please leave it alone.  Thx.

Message #40 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Paul Griepentrog <pgriepen <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Adrian Robert <adrian.b.robert <at> gmail.com>,
	6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 01 Aug 2010 10:38:01 -0700

 On 7/31/10 5:04 PM, Stefan Monnier wrote:
> > and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?
>
>  Actually, we might want to do that everywhere, rather than only in
>  x-win.el and ns-win.el.

Thinking more about the problem, I think the confusion comes from
a perfect storm of evolution:

  - The [backtab] key does not exist on modern keyboards, but
    several modes define keybindings only for [backtab].  (See
    erc, grep, compile, ses, diff-mode and log-view.)

  - But, X and Windows translate [S-tab] into [backtab], so you
    don't even notice this unless you're working on a platform/
    terminal without this mapping, for example: Mac OS X.

  - Add to that: people treat [backtab] as logically the same as
    [S-tab], even though they are different key presses when you
    have a [backtab] key.

As a developer, I would be confused.  I need to map both for my
mode to be consistent across terminals/platforms.  Several modes
do this exactly.  (See forms, info, widget, org, and mh.)

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.  Update all the modes using
[backtab] to use [S-tab].  Now, anybody who has a [backtab] key
can actually use it, and the rest continue with [S-tab], like
they always did.  For compatibility with external modes, we could
map [backtab] to [S-tab].

I can offer a patch to this effect.

Message #43 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Paul Griepentrog'" <pgriepen <at> gmail.com>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: RE: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 1 Aug 2010 11:59:18 -0700

I probably muddied the waters with my previous post.  I was concerned about our
default-binding S-tab unnecessarily to a _command_.  But I see now that that is
not what you are discussing.

I have no problem in general with treating S-tab and backtab as the same key,
for the reason Paul mentioned: there is no physical backtab key (typically).

Sorry for the noise.  I was thinking that this was about binding S-tab to a
backward navigation _command_, such as we do now in Info.  My bad.

Message #46 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>,
	'Paul Griepentrog' <pgriepen <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 02 Aug 2010 01:32:52 +0200

>> > and binding [S-tab] to [backtab] in the 
>> `ns-alternatives-map' instead?
>> Actually, we might want to do that everywhere, rather than only in
>> x-win.el and ns-win.el.
> I disagree.  S-TAB has always been a free global key, and it has
> remained free in most keymaps.

IIUC you don't disagree, you just misunderstand: the binding from S-tab
to backtab is via function-key-map, i.e. it's only used if there's no
binding to S-tab.  IOW it's just a fallback.


        Stefan

Message #49 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Griepentrog <pgriepen <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Adrian Robert <adrian.b.robert <at> gmail.com>,
	6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 02 Aug 2010 02:03:11 +0200

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


        Stefan

Message #52 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>,
	'Paul Griepentrog' <pgriepen <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: RE: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 1 Aug 2010 18:51:13 -0700

> >> > and binding [S-tab] to [backtab] in the 
> >> `ns-alternatives-map' instead?
> >> Actually, we might want to do that everywhere, rather than only in
> >> x-win.el and ns-win.el.
>
> > I disagree.  S-TAB has always been a free global key, and it has
> > remained free in most keymaps.
> 
> IIUC you don't disagree, you just misunderstand: the binding 
> from S-tab to backtab is via function-key-map, i.e. it's only
> used if there's no binding to S-tab.  IOW it's just a fallback.

Yes.  I misunderstood.  See my other followup mail.

For some reason, I thought this was about binding a command to S-tab (and
backtab) everywhere.

Message #55 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Paul Griepentrog'" <pgriepen <at> gmail.com>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: RE: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 1 Aug 2010 18:57:50 -0700

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

Message #58 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Paul Griepentrog <pgriepen <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Adrian Robert <adrian.b.robert <at> gmail.com>,
	Drew Adams <drew.adams <at> oracle.com>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Sun, 01 Aug 2010 21:30:26 -0700

 On 8/1/10 5:03 PM, Stefan Monnier wrote:
> > 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.

Works for me.  I wrote a short proposal to Emacs Dev to stretch the
idea to a bigger audience than the bug report, which Adrian closed.

Message #61 received at 6616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Adrian Robert' <adrian.b.robert <at> gmail.com>,
	'Paul Griepentrog' <pgriepen <at> gmail.com>, 6616 <at> debbugs.gnu.org
Subject: Re: bug#6616: S-TAB is mismapped in the *Help* buffer
Date: Mon, 02 Aug 2010 10:22:34 +0200

> Hm. Then perhaps I do disagree.

I still think you don't.

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

Indeed, that's what it's about.

> I would oppose binding either key to some command everywhere,
> "fallback" or not.

It's not bound to anything in global-map, AFAIK.

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

That's the current (new) state in emacs-23 (not yet propagated to trunk).

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

Never heard of `iso-tab' (we have `iso-lefttab', tho, so maybe that's
a hint that there's an `iso-tab' somewhere as well).  Is that event
found under W32, or X11, or when?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.