[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: Tue, 04 Jul 2023 09:54:48 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)

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

reply via email to

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