[Top][All Lists]

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

Re: Info-mode patch

From: Juri Linkov
Subject: Re: Info-mode patch
Date: Mon, 03 Jul 2023 21:45:23 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)

>>> Is there some way to tell interactive  where all propts will be placed, 
>>> without
>>> parsing interactive form and checking strings for interactive codes or 
>>> something
>>> similar awkward?
>> Yes, there is such way by using the variable 
>> 'minibuffer-follows-selected-frame'.
> So at least in theory, by let-bidinging it to nil, it should keep prompt
> on the original frame. I did just quick naive test, and ended up in debugger:
> (defun info-menu-wrapper ()
>   (interactive)
>   (let ((minibuffer-follows-selected-frame nil))
>     (with-selected-window (info-window)
>       (call-interactively #'Info-menu))))
> but perhaps there are more tweacks to it which I am not familiar with, so I'll
> leave it at that.

What happens when you customize minibuffer-follows-selected-frame
to a third possible value that is not nil and not t.  From docs:

   Any other value means the minibuffer will move onto another frame, but
   only when the user starts using a minibuffer there.

I guess this variable is not intended to do what you expected.

But AFAIU, what you need is only to use with-current-buffer
wrapped around the interactive spec?  There is no need
to select another window/frame while reading from the minibuffer?

> About wrapping; I agree that it is messy to go through each and every command 
> as
> I did to modify them, so for old existing commands, it is definitely easier to
> do the wrapping, if possible. I just hope we get a better way for future 
> command
> writing.

I don't like creating wrapper commands too, but it seems there is no
better way, at least no one proposed anything better.

reply via email to

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