Re: Info-mode patch

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Juri Linkov <juri@linkov.net>,  emacs-devel@gnu.org
>> Date: Tue, 27 Jun 2023 14:15:37 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Juri Linkov <juri@linkov.net>
>> >> Cc: emacs-devel@gnu.org
>> >> Date: Mon, 26 Jun 2023 20:56:19 +0300
>> >> 
>> >> > -(defun Info-directory ()
>> >> > +(defun Info-directory (&optional window)
>> >> >    "Go to the Info directory node."
>> >> >    (interactive)
>> >> > -  (Info-find-node "dir" "top"))
>> >> > +  (with-selected-window (or window (info-window))
>> >> > +    (Info-find-node "dir" "top")))
>> >> 
>> >> I wonder why you modified a lot of commands instead of implementing
>> >> a non-intrusive approach of creating standard wrapper commands like
>> >> 
>> >>   (defun Info-directory-other-window (&optional window)
>> >>      "Go to the Info directory node in another window."
>> >>      (interactive)
>> >>      (with-selected-window (or window (info-window))
>> >>        (Info-directory)))
>> >
>> > Someone, I think it was Stefan, suggested to use a kind of "universal
>> > window argument", similar to "C-x RET c" (which is bound to
>> > universal-coding-system-argument, and allows to specify a
>> > coding-system for the next command.  Wouldn't that approach resulted
>> > in a cleaner, more elegant solution?
>> 
>> In my personal opinion, after wrestling with this, I don't think there is one
>> single "unisex" modell for all. As I see Lisp functions, especially 
>> interactive
>> commands in Emacs, they are more akin to applications, or small shell 
>> scripts,
>> that can basically do whatever they want. Some of them work on buffers, some 
>> on
>> windows, some can just download stuff from the web. With other words, they
>> should be looked at individually what they do, on case by case basis.
>> 
>> It can also happen that wrapping ends up in as much work, just different in 
>> the
>> long run. One has to create wrappers, in some cases not so trivial, otherwise
>> user will be thrown between minibuffers on different frames, which I don't 
>> think
>> would be pretty from the user perspective, then there is the manual and docs
>> everything etc. It can happen that it is not much less work that has to be 
>> done,
>> but just different work, and it can also happen that it ends up in glitches 
>> on
>> some window managers as described in the original mail and response to Juri.
>
> I think you are trying to solve a much wider, more general, and more
> hard problem than you need to.  Remember, this started as a feature to

Not really. It might appear so, because I talk about general problems with what
a command can do, but on contrary, I said in the mail with patch that it
is possible to achive this without altering Emacs, with the tools already in. We
just need to pay attention how we write commands. See below.

> allow the user invoke help-mode and Info-mode commands from a window
> other than the one showing (help* or *info* buffers.  You are
> describing issues far away from that.

What I am trying to say is that command has to be written with the assumptions
that user can call it from any window and Emacs frame, and that all prompting
should be done in the frame at which user types, so I have reworked info 
commands
to work with those assumptions.

Making a wrapper just to put a call to a command into with-selected-window,
instead of wrapping the body of that command with the same macro, is not so much
better; just different. Sure "less intrusive" on a  command itself, but there is
a new command and then we have two where one can do the jobb.

>> By the way, I could possible remove that optional "window" argument in those 
>> few
>> functions that introduce it and use plist as I did in some other place; it 
>> was
>> just a convenience. In that case no signatures are changed at all; no need to
>> change the manual, possibly it is enough to just mention in News that 
>> info/help
>> commands are callable from other buffers.
>
> The "universal-window-argument" suggestion is precisely so you could
> pass such a "window argument" without actually touching the signature
> of the functions.

Ok. I am not familiar with universal-window-agument suggestion, but sounds to me
like also an attempt to offer you a general solution. In that case you will have
to alter other parts of Emacs instead of info and help only. I have just rewrote
Info functions to work without need to alter anything else in Emacs.

Anyway, if the patch is unnaceptable because of most of info commands being
reworked, then I assume it is not interested to continue with this, so I'll
thank for the valuable input and insights and wait with the excitement for the
solution.

Best regards.