Re: Info-mode patch

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

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

The very same. I used a symbol 'something as the third value.

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

What should I have 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?

As said earlier, that highly depends on the work done in the interactive form;
but for the majority of commands, and those in info.el specifically, it should
be enough I believe. This works:

(defun info-menu-wrapper ()
  (interactive)
  (let ((window (info-window)))
    (with-current-buffer (window-buffer window)
      (let ((args (eval (cadr (interactive-form 'Info-menu)))))
        (with-selected-window window
          (apply #'Info-menu args))))))

I would still take it with a grain of salt that it will do in all cases, you
should test each and every, but in majority cases it should work I think.

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

You were against wrapping everything into with-selected-window, now you
everything wrapped into another function :).

The positive about wrappers is they will work with old commands, and if you turn
that into a:core package in Elpa, then even users of older Emacsens can use
it. So I am definitely not against wrappers per se; nor do I believe we should
rewrite each and every user command.

But for writing new commands, I do suggest to implement better macro; because
all this can abstracted away, so we don't double all the commands in the future.