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

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: juri@linkov.net,  manuel@ledu-giraud.fr,  emacs-devel@gnu.org
>> Date: Thu, 01 Jun 2023 15:45:53 +0200
>> 
>> If I try to illustrate with an example: consider a two-window setup with 
>> scratch
>> buffer in first and info buffer in second window. If presses a key to execute
>> next command in other window and then 'm'the system will choose commands from
>> selected window (self-insert command in scratch buffer) and try to execute 
>> that
>> command in other window which is info buffer. Tbat is obviously wrong since 
>> user
>> probably meant to execute Info-menu, by default bound to 'm' in Info-mode.
>> 
>> I don't know if that can be fixed by perhaps manipulating unrread-key-events
>> list or in some other way, perhaps by putting input key back, or by some 
>> other
>> means. I haven't managed to get it correctly and have given up and instead 
>> tre
>> to address the problem in more fundamental way by making those functions 
>> aware
>> of the context they execute in. Also, even if problems could be fixed, I see 
>> no
>> point of using such method in this particular patch.
>
> I don't understand why you see such complexity.  All we need is a
> command that will do
>
>   (with-selected-window (get-buffer-window "*info*")
>     BODY...
No you need a bit more than that sometimes. In case that interactive is doing
some prompting and buffer dependent setup, you will have to wrap interactive
body for itself, and function body for itself. See Info-mode or Info-find (I
think) in patch, but conceptually, yes that is about it. If you can live with
wrapping commands in with-selected-window. Due to fact that interactive form
must be the first form in a function body.

> and then we need to bind it to, say, "C-x 4 h m".  Did I miss
> something important?

Basically that these were two discussions, one where Juri asked me about my
experiences about running commands in other windows, and one about the
patch. Juri dislike the idea of wrapping all commands into with-selected-window
and is trying to find a way to transfer command execution to other window
without need to wrap commands explicitly as I understand him, which I hope he
will find.

The above is discussion about that general command that will send input
to other windows.

Btw, as I understand it, if commands are wrapped in with-selected-window then
yes, they would work with pre/post hack, but it is probably more user friendly
if instead put mode-map on the prefix key, since tools lke which-key will
display a nice pop-up of available stuff in the mode-map, which won't happen in
case of pre/post hook.

>> But for the suggested patch for help and info, I see no reason to use 
>> pre/post
>> hook to switch windows, I can just use with-selected-window which does 
>> exactly the same switching for me in 90% of cases, and manually fix the few
>> cases which needed some extra care.
>
> I didn't say anything about any hooks.

As I understand the confusion: two discussions in one. Perhaps I am just
confused myself :).