Please add S-tab to button-buffer-map

Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Didn't we decide to add S-tab to button-buffer-map? Could someone please 
add this (the binding is the same used in Info-mode-map):

(defvar button-buffer-map
   (let ((map (make-sparse-keymap)))
     (define-key map [?\t] 'forward-button)
     (define-key map [(shift tab)] 'backward-button)
     (define-key map "\e\t" 'backward-button)
     (define-key map [backtab] 'backward-button)
     map)
   "Keymap useful for buffers containing buttons.
Mode-specific keymaps may want to use this as their parent keymap.")

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Didn't we decide to add S-tab to button-buffer-map?

I don't see any discussion in the archives. Perhaps it would be better 
to remap S-tab to backtab globally rather than to tab as it is now.

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > Didn't we decide to add S-tab to button-buffer-map?
> 
> I don't see any discussion in the archives. Perhaps it would 
> be better to remap S-tab to backtab globally rather than to
> tab as it is now.

Please, no.

I have no concrete reason to object.
That just seems, well, like an unnatural act. ;-)

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Drew Adams wrote:
>>> Didn't we decide to add S-tab to button-buffer-map?
>>>       
>> I don't see any discussion in the archives. Perhaps it would 
>> be better to remap S-tab to backtab globally rather than to
>> tab as it is now.
>>     
>
> Please, no.
>
> I have no concrete reason to object.
> That just seems, well, like an unnatural act. ;-)
>   

Actually, it is already mapped to backtab in w32-win.el and x-win.el in 
Emacs 22.1. But this seems to have been lost in the trunk (probably 
after one of the major merges).

Re: Please add S-tab to button-buffer-map

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Drew Adams wrote:
>>>> Didn't we decide to add S-tab to button-buffer-map?
>>>>       
>>> I don't see any discussion in the archives. Perhaps it would be better
>>> to remap S-tab to backtab globally rather than to
>>> tab as it is now.
>>>     
>>
>> Please, no.
>>
>> I have no concrete reason to object.
>> That just seems, well, like an unnatural act. ;-)
>>   
>
> Actually, it is already mapped to backtab in w32-win.el and x-win.el in
> Emacs 22.1. But this seems to have been lost in the trunk (probably after
> one of the major merges).

It was removed from w32-win.el together with the removal of
x-setup-function-keys.  x-win.el still binds (S-)iso-lefttab in the
trunk.

$ git log -Sbacktab lisp/term/w32-win.el
commit 7936b0a847f94687c9916e6c0c67a71dc611e85e
Author: Jason Rumney <jasonr@gnu.org>
Date:   Wed Nov 21 03:40:21 2007 +0000

    (x-setup-function-keys): Remove.

commit a338357dc8cb4b79a8ab00bb447007438bfedb85
Author: Juri Linkov <juri@jurta.org>
Date:   Mon Nov 28 21:19:59 2005 +0000

    Bind [S-tab] to [backtab].

Andreas.

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

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Andreas Schwab wrote:
> It was removed from w32-win.el together with the removal of
> x-setup-function-keys.  x-win.el still binds (S-)iso-lefttab in the
> trunk.
>   

Thanks for the pointer. That change moved x-setup-function-keys to 
w32-fns.el to make the keys available on both windowed and console 
sessions, but an earlier change I made around the time of the multi-tty 
merge synced w32-win.el with x-win.el, which lost the S-tab binding that 
is necessary on Windows, since iso-lefttab is not distinguished from tab 
by the OS.

Re: Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Andreas Schwab wrote:
>> It was removed from w32-win.el together with the removal of
>> x-setup-function-keys.  x-win.el still binds (S-)iso-lefttab in the
>> trunk.
>>   
> 
> Thanks for the pointer. That change moved x-setup-function-keys to 
> w32-fns.el to make the keys available on both windowed and console 
> sessions, but an earlier change I made around the time of the multi-tty 
> merge synced w32-win.el with x-win.el, which lost the S-tab binding that 
> is necessary on Windows, since iso-lefttab is not distinguished from tab 
> by the OS.

But why does the binding to S-Tab in Info work then?

IMO it looks better to bind to S-Tab since that is what the user sees. 
Eh, at least on w32 ... You use S-tab in your web browser for example.

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> But why does the binding to S-Tab in Info work then?

info explicitly binds it as well as binding backtab.

> IMO it looks better to bind to S-Tab since that is what the user sees.

If the user looks closely at their keyboard, they might see a backtab 
symbol on the tab key, printed in the location where the shifted 
representation is expected to be.

Rather than expecting all modes to bind backtab, S-tab, iso-lefttab and 
S-iso-lefttab consistently, to cover all the possible representations 
that a terminal might give that key, we use function-key-map to map them 
all to backtab.

Re: Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> But why does the binding to S-Tab in Info work then?
> 
> info explicitly binds it as well as binding backtab.

Yes, I noticed.

>> IMO it looks better to bind to S-Tab since that is what the user sees.
> 
> If the user looks closely at their keyboard, they might see a backtab 
> symbol on the tab key, printed in the location where the shifted 
> representation is expected to be.
> 
> Rather than expecting all modes to bind backtab, S-tab, iso-lefttab and 
> S-iso-lefttab consistently, to cover all the possible representations 
> that a terminal might give that key, we use function-key-map to map them 
> all to backtab.

Ah, thanks, I never saw that symbol before and had no idea what backtab was.

Re: Please add S-tab to button-buffer-map

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 19 Mar 2008 15:19:52 -0700
> Cc: 'Emacs Devel' <emacs-devel@gnu.org>
> 
> > > Didn't we decide to add S-tab to button-buffer-map?
> > 
> > I don't see any discussion in the archives. Perhaps it would 
> > be better to remap S-tab to backtab globally rather than to
> > tab as it is now.
> 
> Please, no.
> 
> I have no concrete reason to object.
> That just seems, well, like an unnatural act. ;-)

S-TAB acts as backtab in almost every GUI program on Windows.

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > > I don't see any discussion in the archives. Perhaps it would 
> > > be better to remap S-tab to backtab globally rather than to
> > > tab as it is now.
> > 
> > Please, no.
> > 
> > I have no concrete reason to object.
> > That just seems, well, like an unnatural act. ;-)
> 
> S-TAB acts as backtab in almost every GUI program on Windows.

And C-a selects everything. And TAB doesn't do indentation or completion.
And C-M-delete reboots. And...  So what?

I have no objection to S-TAB going to the previous field whenever TAB goes
to the next field. Other than such a context, it seems unnatural. 

Next-field navigation is not the default behavior of TAB in most contexts.
Why should previous-field navigation be the default behavior of S-TAB in all
contexts (globally)?

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Drew Adams wrote:
> Next-field navigation is not the default behavior of TAB in most contexts.
> Why should previous-field navigation be the default behavior of S-TAB in all
> contexts (globally)?
>   

Globally, backtab is undefined. It is only defined as previous-field 
navigation in button-buffer-map.

Re: Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Drew Adams wrote:
>> Next-field navigation is not the default behavior of TAB in most 
>> contexts.
>> Why should previous-field navigation be the default behavior of S-TAB 
>> in all
>> contexts (globally)?
>>   
> 
> Globally, backtab is undefined. It is only defined as previous-field 
> navigation in button-buffer-map.

And I guess that is what is needed, thanks.

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > Next-field navigation is not the default behavior of TAB in 
> > most contexts. Why should previous-field navigation be the
> > default behavior of S-TAB in all contexts (globally)?
> 
> Globally, backtab is undefined. It is only defined as previous-field 
> navigation in button-buffer-map.

Then there should be no problem. Again, I have no problem with S-TAB being
the reverse of TAB when TAB navigates forward among fields.

What I said seemed unnatural was this:

>> Perhaps it would be better to remap S-tab to backtab
>> _globally_ rather than to tab as it is now.

Re: Please add S-tab to button-buffer-map

[Jason Rumney]

Drew Adams wrote:
> What I said seemed unnatural was this:
>   

For something you have no concrete objection to, you are spending a lot 
of effort arguing about it. This mapping goes back 11 years to before 
20.1. The recent breakage on Windows was a bug.

Re: Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Drew Adams wrote:
>> Next-field navigation is not the default behavior of TAB in most 
>> contexts.
>> Why should previous-field navigation be the default behavior of S-TAB 
>> in all
>> contexts (globally)?
>>   
> 
> Globally, backtab is undefined. It is only defined as previous-field 
> navigation in button-buffer-map.

Maybe it should be used in Info too? (Info binds [(shift tab)] now.)

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > What I said seemed unnatural was this:
> 
> For something you have no concrete objection to, you are 
> spending a lot of effort arguing about it.

You're right. I really don't have a concrete complaint against the change.
But the burden for a change should be on the person proposing it - why
change?

> This mapping goes back 11 years to before 
> 20.1. The recent breakage on Windows was a bug.

I didn't realize that. I thought this was a new change proposal. "Perhaps it
would be better to remap..." sounded like a new change, to me.

If this is only a bug (and a regression, at that, and against a long
history), then why bring it up for discussion as a change? No one objects to
a regression fix.

Re: Please add S-tab to button-buffer-map

[Lennart Borgman (gmail)]

Drew Adams wrote:
> If this is only a bug (and a regression, at that, and against a long
> history), then why bring it up for discussion as a change? No one objects to
> a regression fix.

My fault, I did not remember how the discussion ended the last time 
about this. (Maybe because I did not understand that backtab thing ;-)

Re: Please add S-tab to button-buffer-map

[Stefan Monnier]

> I have no objection to S-TAB going to the previous field whenever TAB goes
> to the next field. Other than such a context, it seems unnatural. 

S-TAB is its own key.  It is only remapped to backtab via
function-key-map, i.e. it is only treated as backtab in case there's no
binding for S-TAB.
Furthermore backtab is not bound by default anyway.
So your fears are simply unfounded.


        Stefan

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > I have no objection to S-TAB going to the previous field 
> > whenever TAB goes to the next field. Other than such a
> > context, it seems unnatural. 
> 
> S-TAB is its own key.  It is only remapped to backtab via
> function-key-map, i.e. it is only treated as backtab in case 
> there's no binding for S-TAB.
> Furthermore backtab is not bound by default anyway.
> So your fears are simply unfounded.

I understood that this is about a fallback binding in case there is none. 

IIUC, today there is already such a fallback binding: S-tab is treated like
tab. This change would treat it like backtab instead. The current fallback
(S-tab -> tab) seems more natural to me - that's all I was saying. No fears
were expressed or implied.

Re: Please add S-tab to button-buffer-map

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <jasonr@gnu.org>, <lennart.borgman@gmail.com>, <emacs-devel@gnu.org>
> Date: Thu, 20 Mar 2008 13:43:09 -0700
> 
> > > > I don't see any discussion in the archives. Perhaps it would 
> > > > be better to remap S-tab to backtab globally rather than to
> > > > tab as it is now.
> > > 
> > > Please, no.
> > > 
> > > I have no concrete reason to object.
> > > That just seems, well, like an unnatural act. ;-)
> > 
> > S-TAB acts as backtab in almost every GUI program on Windows.
> 
> And C-a selects everything. And TAB doesn't do indentation or completion.
> And C-M-delete reboots. And...  So what?

So the ``seems unnatural'' argument of yours is, well, unnatural.

RE: Please add S-tab to button-buffer-map

[Drew Adams]

> > > > > I don't see any discussion in the archives.
Perhaps it would 
> > > > > be better to remap S-tab to backtab globally
rather than to
> > > > > tab as it is now.
> > > > 
> > > > Please, no. I have no concrete reason to object.
> > > > That just seems, well, like an unnatural act. ;-)
> > > 
> > > S-TAB acts as backtab in almost every GUI program on
Windows.
> > 
> > And C-a selects everything. And TAB doesn't do
indentation 
> > or completion. And C-M-delete reboots. And...  So what?
> 
> So the ``seems unnatural'' argument of yours is, well,
unnatural.

Whatever. If such reasoning makes sense to you, fine.

I find the fallback position of S-tab working like tab to be
more natural than a fallback position of S-tab working like
backtab. That's the general convention we've followed in
Emacs, and it makes sense to me in this specific case too.

Do as you like. As I said, this is no biggee. Just expressed
an opinion.