Help buffer key bindings

Help buffer key bindings

[Lennart Borgman]

Two things:

*** 1) On EmacsWiki I found this suggestion:

    Bind "l" to help-go-back in help-mode, to make it behave a tiny bit 
more like info mode.

    (add-hook 'help-mode-hook (lambda () (define-key help-mode-map "l" 
'help-go-back)))

Maybe binding "l" to help-go-back is a good thing?


*** 2) A while ago we discussed S-TAB in the help buffer. On w32 this 
still moves forward. I think it should move backward. Was there any 
decision on this? How does it work on other platforms?

I remember I did not quite understand what was happening. It seems like 
S-TAB is interpreted as just TAB on w32. Since other applications (for 
example Firefox) recognices S-TAB it looks a bit like a bug.

RE: Help buffer key bindings

[Drew Adams]

        Bind "l" to help-go-back in help-mode, to make it behave a tiny bit
        more like info mode.

        (add-hook 'help-mode-hook (lambda () (define-key help-mode-map "l"
        'help-go-back)))

    Maybe binding "l" to help-go-back is a good thing?

And bind it to the other keys that `Info-history-back' is bound to -
including `mouse-4'.

Actually, I'm not sure that `Info-history-back' ever got bound to `mouse-4'.
IMO, it should - `Info-history-back' should be bound to all of the usual
things that `Back' is bound to in a Web browser (unless those bindings are
already taken).

Like Web pages, Info is a thing that people can browse with the mouse
(without the keyboard) - and many people will use it that way. Of those who
do, many will have 4- or 5-button mice, and will expect `mouse-4' to go back
to previously visited pages (nodes).

Re: Help buffer key bindings

[Stefan Monnier]

> And bind it to the other keys that `Info-history-back' is bound to -
> including `mouse-4'.

Under X11, mouse-4 and mouse-5 are typically used for wheel events, so
they're used by mouse-wheel-mode.


        Stefan

RE: Help buffer key bindings

[Drew Adams]

    > And bind it to the other keys that `Info-history-back' is bound to -
    > including `mouse-4'.

    Under X11, mouse-4 and mouse-5 are typically used for wheel events, so
    they're used by mouse-wheel-mode.

OK, so let the bindings be platform-dependent, to some extent.
Platform-dependence is already coded into the mouse-wheel code (m-wheel.el),
so it wouldn't be setting a new precedent.

We shouldn't design only for the lowest common denominator, anyway -
otherwise, we would eliminate all graphics, fonts, frames, etc. from Emacs.
Mouse-4 and -5 are just "nice-to-haves" - not essential to the basic use of
Emacs, so I don't think a little platform dependence would hurt here. Why
not give non-X11 users this simple convenience they are used to in other
apps?

That's a shame, for X11, BTW (and it seems weird to me - takes away two
mouse buttons, just so you can use the wheel?). I guess that means the same
happens for Web browsers in X11 environments - can't use mouse-4 for Back
and mouse-5 for Forward?

Re: Help buffer key bindings

[Miles Bader]

2005/11/18, Drew Adams <drew.adams@oracle.com>:
> That's a shame, for X11, BTW (and it seems weird to me - takes away two
> mouse buttons, just so you can use the wheel?). I guess that means the same
> happens for Web browsers in X11 environments - can't use mouse-4 for Back
> and mouse-5 for Forward?

Mouse-wheel scroll events are just events from the mouse like any
other, so it certainly makes sense to call them "mouse-4" and
"mouse-5" (the mouse itself doesn't use names, so it's up to
higher-layers to know what a particular event means, and give them
more meaningful names).  If you have more mouse buttons they are
likely called mouse-6, mouse-7, ...

-miles
--
Do not taunt Happy Fun Ball.

RE: Help buffer key bindings

[Drew Adams]

    > That's a shame, for X11, BTW (and it seems weird to me -
    > takes away two mouse buttons, just so you can use the
    > wheel?). I guess that means the same
    > happens for Web browsers in X11 environments - can't use
    > mouse-4 for Back and mouse-5 for Forward?

    Mouse-wheel scroll events are just events from the mouse like any
    other, so it certainly makes sense to call them "mouse-4" and
    "mouse-5" (the mouse itself doesn't use names, so it's up to
    higher-layers to know what a particular event means, and give them
    more meaningful names).  If you have more mouse buttons they are
    likely called mouse-6, mouse-7, ...

Uh, I'm no expert on this, but on Windows, at least, `mouse-4' and `mouse-5'
in Emacs are the 4th and 5th mouse buttons, respectively. And the wheel
works as, well, a wheel (and as `mouse-2', if you push it instead of roll
it).

I do only this to bind the 4th and 5th mouse buttons to Back and Forward:

  (define-key Info-mode-map [mouse-4] 'Info-history-back)
  (define-key Info-mode-map [mouse-5] 'Info-history-forward)

Works like a charm for Windows. As I said, if that's not the case for X11,
that's a pity, but not a reason to not make this binding for other
platforms. And, as I said, mwheel.el already contains platform-dependent
code.

Re: Help buffer key bindings

[Juri Linkov]

> Two things:
>
> *** 1) On EmacsWiki I found this suggestion:
>
>    Bind "l" to help-go-back in help-mode, to make it behave a tiny bit
> more like info mode.
>
>    (add-hook 'help-mode-hook (lambda () (define-key help-mode-map "l"
> 'help-go-back)))
>
> Maybe binding "l" to help-go-back is a good thing?

If we bind "l" to help-go-back, you might start wanting something more
(like using "r" to go forward in history in the Help buffer :-)

Actually I think more tight integration between Info and Help is
a good thing, and "l" is the first step in this direction.

> *** 2) A while ago we discussed S-TAB in the help buffer. On w32 this
> still moves forward. I think it should move backward. Was there any
> decision on this? How does it work on other platforms?

It doesn't work on tty too.

> I remember I did not quite understand what was happening. It seems like
> S-TAB is interpreted as just TAB on w32. Since other applications (for
> example Firefox) recognices S-TAB it looks a bit like a bug.

Perhaps M-TAB should do the same as S-TAB on systems that don't
produce S-TAB, and only in buffers where M-TAB is not bound to
something useful (like `complete-symbol' which is not useful in
the Help buffer).

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Help buffer key bindings

[Drew Adams]

    > Maybe binding "l" to help-go-back is a good thing?

    If we bind "l" to help-go-back, you might start wanting something more
    (like using "r" to go forward in history in the Help buffer :-)

I was going to suggest the same thing, without the smiley. There should be a
command to go forward, and it should be bound, like `l'. And it should be
bound to `mouse-5' (as `mouse-4' should be bound to `help-go-back').

    Actually I think more tight integration between Info and Help is
    a good thing, and "l" is the first step in this direction.

Yes.

Re: Help buffer key bindings

[Henrik Enberg]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 19 Nov 2005 19:26:06 -0800
> 
>     > Maybe binding "l" to help-go-back is a good thing?
> 
>     If we bind "l" to help-go-back, you might start wanting something more
>     (like using "r" to go forward in history in the Help buffer :-)
> 
> I was going to suggest the same thing, without the smiley. There should be a
> command to go forward, and it should be bound, like `l'. And it should be
> bound to `mouse-5' (as `mouse-4' should be bound to `help-go-back').

Isn't that mouse scroll?

RE: Help buffer key bindings

[Drew Adams]

    > I was going to suggest the same thing, without the smiley.
    > There should be a command to go forward, and it should be bound,
    > like `l'.  And it should be bound to `mouse-5' (as `mouse-4'
    > should be bound to `help-go-back').

    Isn't that mouse scroll?

See earlier in this thread.

Yes, mouse-4 and mouse-5 are currently co-opted by X11 for interpretation of
the mouse wheel (hence, mouse scroll). Emacs is currently aligned to X11 in
this regard, which wastes the 4th and 5th mouse buttons for platforms other
than X11.

Emacs treats key sequences mouse-4 and mouse-5 as the 4th and 5th mouse
buttons for platforms other than X11, however. For example, on Windows,
mouse-4 represents the 4th mouse button. Users on non-X11 platforms can thus
bind mouse-4 and mouse-5 to capture the 4th and 5th button events. However,
we have shied away from assigning any standard Emacs behavior for the 4th
and 5th buttons, because of the special treatment for X11.

Note that Emacs does not, for example, reserve mouse-4 and mouse-5 for the
mouse wheel in all cases, and assign, say, keys mouse-6 and mouse-7 to the
4th and 5th buttons.

I argue that Emacs should not limit itself in this way. It is OK that Emacs
respect the X11 limitation when the platform is X11, but it shouldn't do so
otherwise.

Emacs should go ahead and bind the 4th and 5th mouse buttons to standard
behaviors (e.g. Back and Forward in Info and Help). There are at least two
ways to do this:

1. Use, say, mouse-6 and mouse-7 for the 4th and 5th mouse buttons
systematically, for all platforms (because X11 co-opts mouse-4 and mouse-5).

2. Use mouse-4 and mouse-5 for the 4th and 5th mouse buttons for platforms
other than X11.

Re: Help buffer key bindings

[Miles Bader]

2005/11/20, Drew Adams <drew.adams@oracle.com>:
> Emacs should go ahead and bind the 4th and 5th mouse buttons to standard
> behaviors (e.g. Back and Forward in Info and Help). There are at least two
> ways to do this:

Are buttons 4 and 5 really standardized on "forward" and "back", or is
it just what you use?

The mice I've seen with > 3 buttons have had them in apparently random
positions, so it's not an idel question.

-miles
--
Do not taunt Happy Fun Ball.

RE: Help buffer key bindings

[Drew Adams]

    > Emacs should go ahead and bind the 4th and 5th mouse buttons
    to standard
    > behaviors (e.g. Back and Forward in Info and Help). There are
    at least two
    > ways to do this:

    Are buttons 4 and 5 really standardized on "forward" and "back", or is
    it just what you use?

    The mice I've seen with > 3 buttons have had them in apparently random
    positions, so it's not an idel question.

Good question; you're right to raise it. I thought this was pretty standard,
but googling just now indicates that mice with more than 3 buttons are still
fairly uncommon, and there seems to be no super-standard button mapping.

However, from what I could find, the most common multi-button mice are the
MS IntelliPoint and Logitech MouseWare families (those are the driver
names). For the versions that have more than the 3 main buttons (of which,
the middle is also a wheel), the 4th button of both IntelliPoint and
MouseWare is, by default, a navigational Back button for use in applications
like Web browsers. The 5th button is a Forward button. Both are easily
configurable, however, so there is no guarantee, even for these mice, that a
user has buttons 4 and 5 mapped to Back and Forward.

Here is a page that shows these two kinds of multi-button mouse, with their
button mappings:
http://www.tcmagazine.info/articles.php?action=show&id=62&perpage=1&pagenum=
6.

While the terrain of greatest application of such mice seems to be MS
Windows, it seems that both of these mice also work on GNU/Linux.

So, yes, I was wrong in thinking that 4=Back and 5=Forward are standard
mappings. But it also seems like they are perhaps the most common mappings,
today (that could change tomorrow). I'm no expert on this - this is just my
impression. Perhaps someone else has more definite info?

Re: Help buffer key bindings

[Lennart Borgman]

Juri Linkov wrote:

>Perhaps M-TAB should do the same as S-TAB on systems that don't
>produce S-TAB, and only in buffers where M-TAB is not bound to
>something useful (like `complete-symbol' which is not useful in
>the Help buffer).
>  
>
Perhaps, but in the case of w32 the system actually produces S-Tab. I 
think that should be fixed first.

Re: Help buffer key bindings

[Juri Linkov]

>>Perhaps M-TAB should do the same as S-TAB on systems that don't
>>produce S-TAB, and only in buffers where M-TAB is not bound to
>>something useful (like `complete-symbol' which is not useful in
>>the Help buffer).
>>
> Perhaps, but in the case of w32 the system actually produces S-Tab.
> I think that should be fixed first.

If you evaluate on w32:

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

do you get what you want?  If yes, then this should be added
to emacs/lisp/term/pc-win.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Help buffer key bindings

[Lennart Borgman]

Juri Linkov wrote:

>>>Perhaps M-TAB should do the same as S-TAB on systems that don't
>>>produce S-TAB, and only in buffers where M-TAB is not bound to
>>>something useful (like `complete-symbol' which is not useful in
>>>the Help buffer).
>>>
>>>      
>>>
>>Perhaps, but in the case of w32 the system actually produces S-Tab.
>>I think that should be fixed first.
>>    
>>
>
>If you evaluate on w32:
>
>(define-key function-key-map [S-tab] [backtab])
>
>do you get what you want?  If yes, then this should be added
>to emacs/lisp/term/pc-win.el.
>  
>
Yes, thanks, after this S-TAB moves backwards in the Help buffer.

Re: Help buffer key bindings

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 20 Nov 2005 23:45:54 +0200
> Cc: emacs-devel@gnu.org
> 
> If you evaluate on w32:
> 
> (define-key function-key-map [S-tab] [backtab])
> 
> do you get what you want?  If yes, then this should be added
> to emacs/lisp/term/pc-win.el.

You mean w32-win.el, right?  pc-win.el is for the MS-DOS port, not the
Windows port.

Re: Help buffer key bindings

[Juri Linkov]

>> If you evaluate on w32:
>> 
>> (define-key function-key-map [S-tab] [backtab])
>> 
>> do you get what you want?  If yes, then this should be added
>> to emacs/lisp/term/pc-win.el.
>
> You mean w32-win.el, right?  pc-win.el is for the MS-DOS port, not
> the Windows port.

I guess this is correct.  Could you add it to the right place?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Help buffer key bindings

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> Date: Mon, 21 Nov 2005 09:34:46 +0200
> 
> >> If you evaluate on w32:
> >> 
> >> (define-key function-key-map [S-tab] [backtab])
> >> 
> >> do you get what you want?  If yes, then this should be added
> >> to emacs/lisp/term/pc-win.el.
> >
> > You mean w32-win.el, right?  pc-win.el is for the MS-DOS port, not
> > the Windows port.
> 
> I guess this is correct.  Could you add it to the right place?

Sorry, I wasn't following the discussion, so I think it's better if
someone who did follow it install this change in the right place.