Re: Info-mode patch

[Arthur Miller <arthur.miller@live.com>]

Juri Linkov <juri@linkov.net> writes:

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

I believe that generally:

* commands that do not prompt user in any way don't need to care at all
  (just switch to other window)

* commands that prompt, but don't need data from the other window in any
  way, do not need to care either, don't need with-current-buffer
  either, but can't switch before they are done with prompting

* commands that need to do something with data from the target buffer,
  need to use with-current-buffer and can't switch before they are done
  with prompting

In those cases I believe you can generally just wrap interactive part in
with-current-buffer and not worry about it; I wouldn't try to figure out
which one needs to be wrapped, which one does not. I have used
with-selected-window in all help-mode commands because they are in
almost all cases simple, and it will work in all cases (they don't
prompt user generally).

But there can be other classes of commands, for example if command have
to access some data in current buffer, but will act on some other buffer
or window or commands that do not act on buffers but on windows, layout,
etc, for example quit-window.

Again, you have no guarantee what will happen with a command you haven't
looked at since they can do anything. In most cases they will probably
work by just wrapping them in with-current-buffer, but there is no
guarantee.

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

I am callling the function, not the command, on purpose.

> then better to use 'call-interactively'.  'interactive-form' is
> more suitable for being called from the interactive spec of the wrapper.

Sounds like a complication to me, but I am not as advanced with
elisp. Anyway according to the docs interactive-form returns what it
says, the interactive form, which as I understand, can be evaled
separately in another context to create the list of args one can just
pass to the function and not risk extra prompts. I am sure it is
possible to do it in more complicated ways then the above too.

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

Well, for the info.el and help-mode, I do prefer to use the work I have
done. Were some bugs; I forgott the search, but I have fixed it and
everything works fine so I don't need double keymap and wrappers. But I
wouldn't do the same for all modes.

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

I think that should definitely be written about in the manual. I have
used nothing but with-current-buffer, with-selected-frame and
with-selected-window to achieve this. We could have had this all the
time, if we just coded commands in a better way, and we wouldn't even
needed "-other-window" wrappers.

This can also be wrapped in a macro, say define-command, or defcmd, that
does this automatically, so the future commands are callable from either
buffer they act on or an other buffer.

If there was an option to say to Emacs that prompts should always stay
on the frame where a command loop is initiated, then the gymnastics with
wrapping interactive-from into target buffer could be skipped, and new
commands would only need to wrap their body into with-selected-window.