Re: Control help- and Info-mode buffers from other buffers

[Arthur Miller <arthur.miller@live.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Tue, 30 May 2023 07:38:54 +0200
>> 
>> I would like to be able to control Info and Help buffers from other buffers, to
>> lessen switch between windows.
>> 
>> All commands are (should be) completely backwards compatible, so when called
>> from within help- and Info-mode buffers, they should act as before the
>> patch. Some rudimentary error checking is performed to ensure that user has a
>> visible help- and Info-bufers. Mouse commands are not touched (should not be
>> needed).
>> 
>> This patch also introduces two defcustomed prefix keys for help- and
>> Info-mode-map, so they can be assigned a prefix key. I have used somewhat
>> cumbersome to use, C-h M-h for help-mode-map, and C-h M-i Info-mode-map as
>> prefix keys. I personally use M-h and M-i as prefixes, but those are already
>> assigned by default, and since I do understand the conseervative nature of the
>> list, I prefer to default to something cumbersome and let user remap to anything
>> they find suitable. These are just suggestions. It is also completely valid to
>> not define any prefix key, and leave that code completely out, but a
>> pre-defined prefix key does suggest a certain usage pattern.
>
> This is a useful feature, especially the *Help* buffer part (I tend to
> have a separate frame for Info manuals visible at all times).  But to
> be really useful, the key bindings must be very easy and convenient to
> type, because otherwise people will keep switching to the *Help*
> window and doing it from there.

I don't think it is a problem; it should still be valid workflow to do things in
help buffer itself. I see this just as a helper to help diminish some
switching. Those two jump functions are particullary for cases where user would
like to do several actions in help/info buffer. In that case simplicity of  a
single key probably wins. But I do agree that simple to type prefix is to prefer.

> window and doing it from there.  And "C-h M-h" is not easy to type.  I
> hope we will be able to find an easier-typed prefix.

I have used at some point C-h h for help-mode-map and C-h g for Info-mode-map,
but I am not sure those are much better. It still is 4 letter to type at the end.

>> The defcustom init funciton to read user key is adapted from Helm, I am not sure
>> how/if that works with copyrights (I have signed myself, and this re-uses a
>> relatively small piece of code out of Helm).
>
> This is actually unfortunate.  I'd suggest that you rewrite those
> parts from scratch, using just the general ideas, because otherwise I
> envision it to be hard for us to accept the code.

It is basically just two define-key statements, five lines all-in-all; not much
to re-write. I'll see if there is something similar somewhere in Emacs, unless
the writer of that lambda does not want to step in and donate that code to Emacs? :)

>> Perhaps it might be natural to expect this to work even with multiple frames,
>> but it does not. I am not sure what workflow would be, should user be switched
>> to the frame containing the help/info buffer, or should buffer be openend in a
>> new frame?
>
> Why does it matter whether a *Help* or *Info* buffer is shown on
> another frame?  Emacs can be told to select a window showing a buffer
> either on the selected frame, or on any frame, AFAIR.

Yes, I tottally understand that :). That was mostly because I am not so familiar
with Emacs on multiple frames and that part of the API.Second reason is just the
tune ut takes to test all of it. Drew hinted me where to look, so I'll take a try. 

> Thanks.

Thanks for looking at it.