Re: Info-mode patch

[Juri Linkov <juri@linkov.net>]

>>> 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.