emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arthur Miller
Subject: Re: Control help- and Info-mode buffers from other buffers
Date: Sat, 03 Jun 2023 17:06:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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: Sat, 03 Jun 2023 15:53:22 +0200
>> 
>> The interactive form has to be the very first form in a function body, which
>> makes it impossible to just wrap the entire function  into
>> with-selected-window.
>
> I still don't understand why you need the entire function to be
> wrapped in with-selected-window.

Because part in the interactive form would like to do some work in the info 
buffer
too. Since we have called function from some other buffer it simply wont
work before switch to info buffer. 

>> However, that is just a side note as answer to your remark, but 
>> unfortunately I
>> have found that there is a bigger problem. I am not sure if it is Emacs or my
>> X11 window manager, but I do suspect the WM in this case.
>> 
>> I have both in my WM and in Emacs that focus should follow mouse. Now what
>> happens is that, despite the function jumpiing to correct Emacs window on
>> another frame, due to cursor being in old frame, all input goes to the old
>> frame, so at least this particular function does not work with multiple
>> frames.
>
> I don't understand: I thought we were talking about causing the other
> window to do something without the user selecting that window.  So why
> does it matter where input goes? what input do you want to go to the
> non-selected window or frame?

Yes we are; but some functions prompts user for additional input, and if the
info is in another frame but the one with the focus, than minibuffer does not
get the focus, and the input instead goes into the frame where mouse
cursor/point is. See more further down.

> For example, the command "M-PgUp" scrolls "the other" window without
> selecting it, and I don't want in this case to have input switched to
> that other window.  Same will be my expectation when there will be a
> command to show me the source of a function whose doc string is
> displayed in the *Help* buffer shown in the other window: I want just
> to see the source in that other window, I don't want to start typing
> there.
>
> What am I missing or misunderstanding?  Why are you suddenly talking
> about redirecting input?

As above, some functions, like Info-menu, asks use interactively for additional
input, which we type in minibuffer. But since the old frame is selected it is
not possible to type in info frames minibuffer without moving cursor over to
that frame, which defeats the purpose of the patch. Can I somehow tell Emacs to
prompt in minibuffer in current frame? I haven't done this before, so I am
familiar what to look for here.

Perhaps it is enough to do it in info buffer which I can do in with-info-buffer,
now when I think of it; I am not sure if I have tried to be honest. But anyway,
as a general case, the interactive form part has to be take care of separately
from the rest of the function. Just using the buffer instead of switching the
window perhaps solves problem of frame focus when prompted in minibuffer. Sorry
thinking loud :).

>> I do have another question too: what is a good strategy if there are 
>> multiple info
>> windows open? Prompt user to select with a completing read, or just leave 
>> as-is,
>> i.e. return the first info window?
>
> You are talking about a situation where multiple *Help* windows are
> shown?

Not *Help*; I am asking about multiple *info* windows.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]