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: Fri, 02 Jun 2023 03:26:26 +0200
>> 
>> > 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.
>
> You also have call-interactively, which can work around this minor
> obstacle.

Can it? I am talking about interactive "marker" when in defun impelementation; 
not
calling interactive functions. 

>> > 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.
>
> Well, I see no reason to dislike what Juri dislikes in this case.  So
> now you get to choose whose preferences you want to follow ;-)

I hope I am not misunderstood here. I certainly don't dislike what Juri does; on
contrary. I made that Reddit thread because I very much was looking for
something similar, and I am using pre/post hack myself. However I see some
fundamental issue in how Emacs works, which I am not sure can be easily overcom,
but if Juri can fix them I will certainly be a happy user :).

>> The above is discussion about that general command that will send input
>> to other windows.
>
> As I said elsewhere in this thread, trying to make this more general
> than it needs to be is over-engineering.  Not all commands can
> naturally be used with the "other-window prefix", and we are talking
> about help-related commands here.  For help-related commands, it is
> natural to work in another window while having the help displayed
> nearby, and it is therefore natural to control that non-selected help
> window without having to select it first.  So that is what we should
> do, IMO.

We share similar opinion. As I have mentioned elsewhere, even if pre/post-hack
could be used as a general solution, one would still like to make particular
specialization for certain modes like Help, Info and perhaps a handfull of
others, so in that case I can just give up on generality and manually wrap stuff
as I did.

As just a small update, I was able to string-replace all get-buffer-window
according to Drews helpful tip, so now everything seems to work accross the
frames too. However I haven't had time to test each and every function so they
really work, so I will send in a patch probably tomorrow or day after when I
have had time to go through all to ensure they really do work. I have also
removed the prefix-key helper. Theat removed those 5 lines of :set method from
Helm. I guess you or someone else can put in something similar later on, or just
defvar the prefix in source. Probably not meany people use Customize to redefine
their kes anyway.