Re: Info-mode patch

[Juri Linkov]

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

I agree, so commands that don't read the default value from the buffer
don't need even with-current-buffer.

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

If you prefer calling the original command from the body
then better to use 'call-interactively'.  'interactive-form' is
more suitable for being called from the interactive spec of the wrapper.

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

I still think that adding new wrapper commands is less wrong than
wrapping existing commands into with-selected-window.

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

I'm not sure if this should be a new coding convention for writing new commands
that should be mentioned in (info "(elisp) Programming Tips").