[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6616: S-TAB is mismapped in the *Help* buffer
From: |
Paul Griepentrog |
Subject: |
bug#6616: S-TAB is mismapped in the *Help* buffer |
Date: |
Mon, 12 Jul 2010 22:42:14 -0700 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 |
Thanks for looking into this.
On 7/12/10 12:10 PM, Eli Zaretskii wrote:
> From: Adrian Robert <adrian.b.robert@gmail.com>
> Date: Mon, 12 Jul 2010 22:03:11 +0300
> Cc: Paul Griepentrog <pgriepen@gmail.com>,
> 6616@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.
bug#6616: Closing, checked fix in to trunk r100808, Adrian Robert, 2010/07/13