Shift Tab should move backward in help buffers

Shift Tab should move backward in help buffers

[Lennart Borgman]

Tab move to next link in the help buffer. Shift-Tab does the same. 
However it would be more practical and consistent with usual behaviour 
if Shift-Tab moved backwards.

Re: Shift Tab should move backward in help buffers

[David Hunter]

Lennart Borgman wrote:
> Tab move to next link in the help buffer. Shift-Tab does the same. 
> However it would be more practical and consistent with usual behaviour 
> if Shift-Tab moved backwards.

Interesting.  In emacs 21.3 for Windows, a *Help* buffer binds both <S-tab> and <backtab> to 'help-previous-ref', and <S-tab> works as expected.

In emacs 22.0.50.1 (2005-05-24), <S-tab> is not bound, but <backtab> is bound to 'backward-button'.  However, in *Customize Group: Emacs*, <S-tab> IS bound to 'widget-backward'.

I suppose it would be easier to add <S-tab> to 'button-buffer-map'.  'help-mode-map' used to include <S-tab> (changed 1998-04-22 Dave Love), probably up until it started inheriting 'button-buffer-map'.

-Dave

Re: Shift Tab should move backward in help buffers

[David Ponce]

Hello,

> In emacs 22.0.50.1 (2005-05-24), <S-tab> is not bound, but <backtab> is 
> bound to 'backward-button'.  However, in *Customize Group: Emacs*, 
> <S-tab> IS bound to 'widget-backward'.
> 
> I suppose it would be easier to add <S-tab> to 'button-buffer-map'.  
> 'help-mode-map' used to include <S-tab> (changed 1998-04-22 Dave Love), 
> probably up until it started inheriting 'button-buffer-map'.

Please notice that on my Compacq Evo N610c laptop running Fedora Core
3 GNU/Linux the <S-tab> and <backtab> keys seem to not exist.  There
is a <S-iso-lefttab> instead. Perhaps this key could be added to?

David

In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.4.14)
  of 2005-06-26 on localhost
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-gtk'

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: en_US.UTF-8
   locale-coding-system: utf-8
   default-enable-multibyte-characters: t

Re: Shift Tab should move backward in help buffers

[Luc Teirlinck]

David Ponce wrote:

   Please notice that on my Compacq Evo N610c laptop running Fedora Core
   3 GNU/Linux the <S-tab> and <backtab> keys seem to not exist.  There
   is a <S-iso-lefttab> instead. Perhaps this key could be added to?

And it would be useful to have a keybinding that works by default,
even when not using a window system.  <S-tab> does not; by default, it
usually gets translated into <tab>, so it moves forward, not backward.

Sincerely,

Luc.

Re: Shift Tab should move backward in help buffers

[Lennart Borgman]

David Ponce wrote:

> Please notice that on my Compacq Evo N610c laptop running Fedora Core
> 3 GNU/Linux the <S-tab> and <backtab> keys seem to not exist.  There
> is a <S-iso-lefttab> instead. Perhaps this key could be added to?

Should not something else be changed instead? Should not <S-tab> exist 
in all environments?

Re: Shift Tab should move backward in help buffers

[Lennart Borgman]

Luc Teirlinck wrote:

>And it would be useful to have a keybinding that works by default,
>even when not using a window system.  <S-tab> does not; by default, it
>usually gets translated into <tab>, so it moves forward, not backward.
>  
>
Is the problem that Emacs can not see <S-tab> on all systems?

Re: Shift Tab should move backward in help buffers

[Luc Teirlinck]

Lennart Borgman wrote:

   Luc Teirlinck wrote:

   >And it would be useful to have a keybinding that works by default,
   >even when not using a window system.  <S-tab> does not; by default, it
   >usually gets translated into <tab>, so it moves forward, not backward.
   >  
   >
   Is the problem that Emacs can not see <S-tab> on all systems?

The problem is this, form `(elisp)Character Type':

     The case of a graphic character is indicated by its character code;
  for example, ASCII distinguishes between the characters `a' and `A'.
  But ASCII has no way to represent whether a control character is upper
  case or lower case.  Emacs uses the 2**25 bit to indicate that the
  shift key was used in typing a control character.  This distinction is
  possible only when you use X terminals or other special terminals;
  ordinary terminals do not report the distinction to the computer in any way.

and, from `(emacs)Named ASCII Chars':

     With an ordinary ASCII terminal, there is no way to distinguish
  between <TAB> and `C-i' (and likewise for other such pairs), because
  the terminal sends the same character in both cases.

So, from the console and from `emacs -nw', <tab>, <S-tab>, C-i and
S-C-i are indistinguishable.

`emacs -nw' is important to people with a slow connection, because
just emacs without `-nw' over a slow connection is just way to slow to
be usable.

Sincerely,

Luc.

Re: Shift Tab should move backward in help buffers

[Andreas Schwab]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> So, from the console and from `emacs -nw', <tab>, <S-tab>, C-i and
> S-C-i are indistinguishable.

Depends on the terminal.  At least S-tab is sometimes recognizable as
backtab, like on xterm (where S-tab sends "ESC [ Z", detected via terminfo
kcbt).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Shift Tab should move backward in help buffers

[Richard M. Stallman]

    Tab move to next link in the help buffer. Shift-Tab does the same. 
    However it would be more practical and consistent with usual behaviour 
    if Shift-Tab moved backwards.

Would you like to send a patch?

Re: Shift Tab should move backward in help buffers

[Miles Bader]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> Should not something else be changed instead? Should not <S-tab> exist 
> in all environments?

Presumably you mean "all non-terminal environments"...

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Shift Tab should move backward in help buffers

[David Hunter]

Andreas Schwab wrote:

> Depends on the terminal.  At least S-tab is sometimes recognizable as
> backtab, like on xterm (where S-tab sends "ESC [ Z", detected via terminfo
> kcbt).

Hmm... so, in all keymaps that want to bind a backwards tab, you'd have to do this to make everyone happy:

    (define-key map [backtab] 'backward-button)
    (define-key map [(shift tab)] 'backward-button)
    (define-key map [iso-lefttab] 'backward-button)
    (define-key map [(shift iso-lefttab)] 'backward-button)

Ugh.  Why not force the window terminal customizations (e.g., w32-term.el) to "bind" such tabs to [backtab], just like x-win.el already does:

    (define-key function-key-map [(shift tab)] [backtab])
    (define-key map [iso-lefttab] 'backward-button)
    (define-key map [(shift iso-lefttab)] 'backward-button)

So far, the only downside I've seen is that pressing Shift-TAB in a buffer that doesn't bind <backtab> causes a "<backtab> is undefined" error, instead of translating to plain ol' TAB.

-Dave

Re: Shift Tab should move backward in help buffers

[David Hunter]

David Ponce wrote:
> Please notice that on my Compacq Evo N610c laptop running Fedora Core
> 3 GNU/Linux the <S-tab> and <backtab> keys seem to not exist.  There
> is a <S-iso-lefttab> instead. Perhaps this key could be added to?

Does this mean that C-h k (Shift Tab) reports <S-iso-lefttab>?  It seems you're running emacs in X, so you should see "<backtab> (translated from <S-iso-lefttab>)" if the active keymap binds <backtab> to a command.  Unless you're using table-mode or org-mode, which bind <S-iso-lefttab> explicitly.

-Dave

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/27/05, David Hunter <hunterd_42@comcast.net> wrote:
> Ugh.  Why not force the window terminal customizations (e.g., w32-term.el) to "bind" such tabs to [backtab], just like x-win.el already does:
> 
>     (define-key function-key-map [(shift tab)] [backtab])
>     (define-key map [iso-lefttab] 'backward-button)
>     (define-key map [(shift iso-lefttab)] 'backward-button)

I'm a bit confused by your example above -- did you really mean:

   (define-key function-key-map [(shift tab)] [backtab])
   (define-key function-key-map [iso-lefttab] [backtab])
   ;; ...etc...

   (define-key map [backtab] 'backward-button)
   ;; no etc.

?

I'd think the majority of the function-key-map bindings should be done
centrally though, not in terminal specific files (though maybe a few
weird ones would be done in the latter).

Thanks,

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[David PONCE]

Hello,

>> Please notice that on my Compacq Evo N610c laptop running Fedora Core
>> 3 GNU/Linux the <S-tab> and <backtab> keys seem to not exist.  There
>> is a <S-iso-lefttab> instead. Perhaps this key could be added to?
> 
> 
> Does this mean that C-h k (Shift Tab) reports <S-iso-lefttab>?  It seems 
> you're running emacs in X, so you should see "<backtab> (translated from 
> <S-iso-lefttab>)" if the active keymap binds <backtab> to a command.  
> Unless you're using table-mode or org-mode, which bind <S-iso-lefttab> 
> explicitly.

You're right.  In fact I had an explicit global key binding to
<S-iso-lefttab> in my start-up file, so I didn't see anymore the
<backtab> key.  I changed to use <backtab> instead of <S-iso-lefttab>
and it works now.

However I also have a global key binding to <C-backtab> which doesn't
work, I only see <C-S-iso-lefttab>.  I also tried without any user's
configuration:

emacs -Q

C-h k reported:

<backtab> (translated from <S-iso-lefttab>) is undefined

<C-S-iso-lefttab> is undefined

ESC <backtab> (translated from <escape> <S-iso-lefttab>) is undefined

ESC <C-S-iso-lefttab> (translated from <escape> <C-S-iso-lefttab>) is
undefined


Is it the expected behavior?  IMHO, with the control key, backtab
should report <C-backtab> for consistency.  WDYT?

Thanks.

Sincerely,
David 

In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.4.14)
 of 2005-06-26 on localhost
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-gtk'

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: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Re: Shift Tab should move backward in help buffers

[Jason Rumney]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Tab move to next link in the help buffer. Shift-Tab does the same. 
>     However it would be more practical and consistent with usual behaviour 
>     if Shift-Tab moved backwards.
>
> Would you like to send a patch?

The current defaults are:

<S-tab>   aliased to TAB
<backtab> unbound

As far as I can tell, <backtab> and <S-tab> are generated for the same
keys on different terminals (or do some terminals have a separate
backtab key?).

So it may be more consistent for the defaults to be:

<S-tab>   aliased to backtab
<backtab> aliased to TAB


Then if a mode like help-mode defines an alternate binding for
backtab, S-tab will automatically follow. We'd have to check the
codebase for S-tab bindings and change them to bind backtab instead to
maintain consistency.

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote:
> We'd have to check the
> codebase for S-tab bindings and change them to bind backtab instead to
> maintain consistency.

Yes, but I think we'd have to do that anyway -- the current state of
things is sort of ridiculous.

I definitely vote for centralizing the mappings and standardizing on
<backtab> for the various mode-specific keymaps.

[I'm not even sure that maintaining a default aliasing of S-TAB -> TAB
is very important -- this feature is handy for the alphabetic keys for
several reasons, but I don't think it matters very much for keys like
TAB.]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[David Hunter]

Miles Bader wrote:
> I'm a bit confused by your example above -- did you really mean:
> 
>    (define-key function-key-map [(shift tab)] [backtab])
>    (define-key function-key-map [iso-lefttab] [backtab])
>    ;; ...etc...
> 
>    (define-key map [backtab] 'backward-button)
>    ;; no etc.

You saw right thru my cut-and-waste error. :)

> I'd think the majority of the function-key-map bindings should be done
> centrally though, not in terminal specific files (though maybe a few
> weird ones would be done in the latter).

What central location did you have in mind?  bindings.el looks promising.

-Dave

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/28/05, David Hunter <hunterd_42@comcast.net> wrote:
> What central location did you have in mind?  bindings.el looks promising.

Yes, that's what was thinking of.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[David Hunter]

David PONCE wrote:
> However I also have a global key binding to <C-backtab> which doesn't
> work, I only see <C-S-iso-lefttab>.  I also tried without any user's
> configuration:
> 
> Is it the expected behavior?  IMHO, with the control key, backtab
> should report <C-backtab> for consistency.  WDYT?

I think the current behavior of matching a key exactly is sensibly conservative.  Custom key building should be done explicitly.  You didn't actually press backtab; you pressed control, shift, and Tab.

You'll need to learn Emacs what you mean:

  (define-key function-key-map [C-S-iso-lefttab] [C-backtab])

-Dave

Re: Shift Tab should move backward in help buffers

[Richard M. Stallman]

    So it may be more consistent for the defaults to be:

    <S-tab>   aliased to backtab
    <backtab> aliased to TAB

That seems plausible to me, in spirit, but I am not sure it is
possible.  function-key-map operates just once on the input event
stream, and then key-translation-map operates once.  It could be that
on some terminals S-tab is represented by an escape sequence which is
decoded by function-key-map, so there is no way to translate it twice
more.

Thus, clean as this is, we can't do it without creating some
new mechanism.  And I don't think it's worth creating a new
mechanism just for this.

    [I'm not even sure that maintaining a default aliasing of S-TAB -> TAB
    is very important -- this feature is handy for the alphabetic keys for
    several reasons, but I don't think it matters very much for keys like
    TAB.]

I agree with that.  It isn't crucial for either S-tab or backtab to
alias to TAB.

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/28/05, Richard M. Stallman <rms@gnu.org> wrote:
> It could be that
> on some terminals S-tab is represented by an escape sequence which is
> decoded by function-key-map, so there is no way to translate it twice
> more.

The code which sets up the escape mappings for those terminals could
set up an explicit direct mapping for "escape-sequence -> backtab"
(bypassing the S-tab step) couldn't they?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[Stefan Monnier]

> The code which sets up the escape mappings for those terminals could
> set up an explicit direct mapping for "escape-sequence -> backtab"
> (bypassing the S-tab step) couldn't they?

Except that it would not correctly handle the case where the user has bound
S-tab to something.

The answer is (as has been mentioned on this list a while back) that
terminal-escape-sequences should not be handled with function-key-map but
with a new map placed before function-key-map (and applied unconditionally,
like key-translation-map but unlike function-key-map).


        Stefan

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/28/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> The answer is (as has been mentioned on this list a while back) that
> terminal-escape-sequences should not be handled with function-key-map but
> with a new map placed before function-key-map (and applied unconditionally,
> like key-translation-map but unlike function-key-map).

Does the other thread talk about other bugs that would be fixed?

Richard didn't seem to like the idea of adding a new feature for this,
but it _sounds_ pretty simple (to add an unconditional translation
layer), and if it fixes other bugs too... well... I dunno.

BTW, do we really care about user bindings of S-TAB that much? 
Couldn't we just tell them to bind backtab instead?  It seems very
likely that most user code that binds S-TAB does same thing as the
packages we've discussed in this thread (bind 2-3 variants but
essentially meaning backtab), and would either already work with
backtab, or it it would be clean to modify them to bind backtab too.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[Stefan Monnier]

>> The answer is (as has been mentioned on this list a while back) that
>> terminal-escape-sequences should not be handled with function-key-map but
>> with a new map placed before function-key-map (and applied unconditionally,
>> like key-translation-map but unlike function-key-map).

> Does the other thread talk about other bugs that would be fixed?

Yes, tho I can't offhand remember which ones.  It may have to do with the
C-x 8 thingy, or maybe with terminal coding systems that use ESC sequences,
but I really can't remember.

> Richard didn't seem to like the idea of adding a new feature for this,
> but it _sounds_ pretty simple (to add an unconditional translation
> layer), and if it fixes other bugs too... well... I dunno.

I'd rather postpone all this to post-22.1.  I've been impatiently waiting
for the next major Emacs release for several years now and we have more than
plenty new features already.


        Stefan

Re: Shift Tab should move backward in help buffers

[LENNART BORGMAN]

From: Miles Bader <snogglethorpe@gmail.com>

> BTW, do we really care about user bindings of S-TAB that much? 
> Couldn't we just tell them to bind backtab instead?  It seems very
> likely that most user code that binds S-TAB does same thing as the
> packages we've discussed in this thread (bind 2-3 variants but
> essentially meaning backtab), and would either already work with
> backtab, or it it would be clean to modify them to bind backtab too.

Where is backtab on a pc running ms windows?

Re: Shift Tab should move backward in help buffers

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The code which sets up the escape mappings for those terminals could
>> set up an explicit direct mapping for "escape-sequence -> backtab"
>> (bypassing the S-tab step) couldn't they?
>
> Except that it would not correctly handle the case where the user has bound
> S-tab to something.

On those terminals S-tab does not exist, it is recoginized directly as
backtab.  At least terminfo does not have a way to denote S-tab, only
backtab.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Shift Tab should move backward in help buffers

[Eli Zaretskii]

> Date: Tue, 28 Jun 2005 10:42:55 +0200
> From: LENNART BORGMAN <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, rms@gnu.org
> 
> Where is backtab on a pc running ms windows?

Should be S-TAB, I think.

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/28/05, Andreas Schwab <schwab@suse.de> wrote:
> On those terminals S-tab does not exist, it is recoginized directly as
> backtab.  At least terminfo does not have a way to denote S-tab, only
> backtab. 

This makes it sound to me like it's pretty safe to implement the
discussed central remappings then, and not worry about the conjectured
"double translation" issue.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[Richard M. Stallman]

    The code which sets up the escape mappings for those terminals could
    set up an explicit direct mapping for "escape-sequence -> backtab"
    (bypassing the S-tab step) couldn't they?

I think so.  In effect, this would mean deciding that Emacs should
always deal with backtab, never with S-tab.  (We would want
function-key-map to map S-tab into backtab also, to ensure that this
is true even on systems that produce S-tab directly.)

That could be part of the solution to this problem.

Stefan wrote:

    Except that it would not correctly handle the case where the user has bound
    S-tab to something.

That is true, but we'd just tell the users that nowadays they
should bind backtab because Emacs no longer uses S-tab.

Re: Shift Tab should move backward in help buffers

[Miles Bader]

On 6/29/05, Richard M. Stallman <rms@gnu.org> wrote:
>     The code which sets up the escape mappings for those terminals could
>     set up an explicit direct mapping for "escape-sequence -> backtab"
>     (bypassing the S-tab step) couldn't they?
> 
> I think so.  In effect, this would mean deciding that Emacs should
> always deal with backtab, never with S-tab.  (We would want
> function-key-map to map S-tab into backtab also, to ensure that this
> is true even on systems that produce S-tab directly.)

I think that is a reasonable solution for this release; if some more
sophisticated handling turns out to be desirable, it can probably wait
until the next release.

So unless there are strong objections, I'll implement that by default
(well unless somebody else wants to implement it; David?).

Are there funny names for backtab other than those mentioned in this thread?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Shift Tab should move backward in help buffers

[David Hunter]

Miles Bader wrote:
> So unless there are strong objections, I'll implement that by default
> (well unless somebody else wants to implement it; David?).

Go for it.  Work has been keeping me otherwise occupied.

> Are there funny names for backtab other than those mentioned in this thread?

Look for the [(shift key)] variants, as opposed to [S-key].  For example, [(shift iso-lefttab)] and [(shift tab)].  They're for emacsen intercompatibility.

-Dave