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>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  manuel@ledu-giraud.fr,  emacs-devel@gnu.org
>> Date: Thu, 01 Jun 2023 11:16:50 +0200
>> 
>> In general, (I think) that allow to support commands that are available in
>> selected-window, to be executed in other-window, but does not have access to
>> commands defined in other-window, and naturally we can't executed commands from
>> selected-window if they are not supported in other-window. With other words, if
>> set of commands from selected window is S and set of commands in other-window is
>> O, than this will work in on the intersect of those commands, S∩O. Perhaps there
>> is more to it, but I think that is the minimal requirement (the commands has to
>> work on both buffers).
>
> I'm sorry, I don't understand what you are trying to say here.  What
> exactly is the minimum requirement, and why?

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.

Sure, the hack has definitely a value on its own, and please, include it in
Emacs if you get some good understanding and robust error handling for it.

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.

>> Potentially it can also result in many bug repports and /r/Emacs threads where
>> people wonder why it does not work some command Foo in other buffer.
>
> If we have a good reason why it doesn't work, we will explain it.  And
> if we don't have a good reason, we can add another binding.  Where's
> the problem?

Yes, I understand that, and that is why I am also discussing it and trying to
bring to the table what is my understanding of the process involved. I don't
consider myself to understand everything going on in interaction between
commands and pre/post command hooks.

For example what happends if a command call
another command and it happen to have post hooks? Will it run after the second
command call internally (I think it will), which means it will switch back to
old window prematurely.