Re: Info-mode patch

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>>>> (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.
>
> It would be inconsistent to call interactive-form in the body.

Incosistent with what?

> Better to do this in the interactive spec:
>
>   (defun info-menu-wrapper (window &rest args)
>     (interactive
>      (let ((window (info-window)))
>        (with-current-buffer (window-buffer window)
>          (cons window (eval (cadr (interactive-form 'Info-menu)))))))
>     (with-selected-window window
>       (apply #'Info-menu args)))

As said; there are always more complicated ways :).

To start with, observe that I was not discussing how you should
implement your patch. You wanted to confirm if it is enough to just wrap
in with-current-buffer, so I prototyped a few lines just for the
illustration of the idea.

If you are going to send aguments to your wrapper, sure, I can
understand you would want to do it in the interactive form, but for your
example, I am not sure why are you sending the twindow and args 
in. I guess you are making some sore of a framework, but if you are
keeping *some* sort of automated guessing framework, such as info-window
than I see no point of sending in that window argument. Now, I don't
know what you do, and how your framework looks like, but I would either
keep exactly the same arguments as in the wrapped function, or take the
opportunity and get rid of all arguments in the wrapper. I don't think
you need them.

That would make possible code generator easier to implement, and
it would be easier to potential users write their own lambdas and so on.

>> 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.
>
> Such option could be added to the third argument of the interactive spec.

*Iff* such hypothetical variable existed, then it certainly should be
 the users choice to decide where prompts are shown, not the 3rd party
 code. I think the variable you pointed me too that didn't do "what I
 expected", could be used, perhaps with some new symbol as the value,
 or perhaps the nil value just does not work as advertised?

Anyway, it should ceartainly be left to the user to customize where
 prompts are shown. Mode/library/command writers should neither have to
 bother with that decision or be allowed to decide for the user where
 prompts should display.
 
> There is a new feature added in Emacs 28 where the second argument defines
> to which mode the command is applicable, for example, Info-mode:

I know. Two days ago I ported my patched info.el to separate package and
to older versions. Porting it back all the way to 25 was relatively
painless and trivial, minus reworked interactive spec which causes older
version to omit a sea of warnings about maligned interactive spec. Seems
like the the warning is not defined as a symbol, I just see
byte-compile-warn-x emit it as a string, I don't see it defined as a
symbol so I am not sure how to turn it off without further hacking.

>   (interactive "P" Info-mode)
>
> The third argument could define which window the command should select.
> For example:
>
>   (interactive "P" Info-mode (info-window))

I personally wouldn't do that. You only need this for commands that are
already written, not for new commands. For those that already are in
existence, I think you can simplify with a simple wrapper that does not
take arguments as I did in the protytope and as discussed above. At
least I think so; pehaps I am missing some case? 

There is no reason to complicate meaning of interactive spec and to
hardcode what things mean in this regard, at least not just yet. Once
you hardcode that meaning we will have to live with that for the rest of
Emacs history, but perhaps it is not needed at all? I understand your
enthusiasm, but let us live with this for a version or two until we get
better understanding how this works in practice and what we need. I
sincerely think you should port few relatively complex commands as I did
in info.el to get understanding for this, if you didn't already.

For new code, I am quite sure we can have a nice macro that takes care
of the details so we don't need to generate wrappers for any new command
that is yet to be written.

I would also wait to introduce those wrappers into Emacs. Perhaps, there
are other solutions too. Perhaps a compiler/gengerato could be written to
translate old commands to more flexible implementation that can work
when called from other windows too, since it is a mechanical
process. Info.el and help-mode.el, as reworked manually, don't require
"-other-window" wrappers; they are fully compatible with repeat mode as
expected and are completely backward compatible with existing lisp code
and user experience. It might be a long shot, but perhaps it is possible
to write a generator that rewrites commands automatically, or better to
say, I know it is possible, perhaps not in 100% cases, but for the
majority of cases. The technical issue is just how to decide which
commands need to be so flexible and which don't. But the real question
is if it would be acceptible.