Re: Info-mode patch

[Juri Linkov]

>>>> But it seems this is not enough because with-selected-frame
>>>> still fails to switch focus to another frame.  You need also
>>>> to use select-frame-set-input-focus.
>>> Where it fails? For me it prompts me on correct frame. I didn't want to 
>>> switch
>>> focus on the info frame. I am aware of select-frame-set-input-focus, have 
>>> used
>>> it in some test actually.
>>
>> Probably the behaviour depends on the window manager.
>
> Yes, I am quite sure it isn't "probably" but "surely" :), as I wrote earlier 
> by
> the way.
>
>> With my window manager with-selected-frame displays
>> the prompt in another frame, but input is inserted
>> into the original buffer.  Maybe we should have
>> a new option whether to use select-frame-set-input-focus?
>
> I am not sure I understand what you mean with input being inserted in the
> original buffer.

For example, the original buffer is *scratch*.  The minibuffer
pops up in another frame.  I start typing.  But letters get
inserted to *scratch*, not to the minibuffer.  This is because
focus is not switched to another frame.

>>> Have you tested *everything*? Interactively and from lisp?
>>
>> I see no problems with this both interactively and from lisp:
>
> If you don't care to ask the user which window to choose when ambigous, then 
> you
> don't have to care about this at all. If you don't want to take care of
> multiple windows with possibly ambigous names, user misstyping a name and
> possibly irregular name, then you don't need to prompt the user at all, just
> take the first info buffer you find or force user to *always* select manually 
> a
> window and you are all good. But in my opinion it is not hard to have it 
> slightly
> more polished and automated as I did. 

I don't know what do you mean by the words "don't care"
since this implementation still uses your function
'info-window' that asks the user which window to choose.
Please look carefully at Info-index-other-window:

>> #+begin_src emacs-lisp
>> (defmacro with-selected-window-frame (window &rest body)
>>   `(let ((old-frame (selected-frame))
>>          (frame (window-frame ,window)))
>>      (unless (eq frame old-frame)
>>        (select-frame frame 'norecord)
>>        (select-frame-set-input-focus frame 'norecord))
>>      (prog1 (with-selected-window ,window
>>               ,@body)
>>        (select-frame old-frame 'norecord)
>>        (select-frame-set-input-focus old-frame 'norecord))))
>>
>> (defun Info-index-other-window (topic &optional window)
>>   (interactive
>>    (with-selected-window-frame (info-window)
>>      (append (eval (cadr (interactive-form 'Info-index)))
>>              (list (selected-window)))))
>>   (with-selected-window (or window (info-window))
>>     (Info-index topic)))
>> #+end_src
>>
>> You can't avoid adding the window argument.  Otherwise, you need
>> to invent such hacks as sending the window selected by the user
>> to the command body via a symbol property.
>>
>> But in the wrapper command like above there is no problem
>> of adding the window argument to the new command.
>
> I wasn't familiar with interactive form enough and didn't know how to connect
> the optional argument from within interactive form. Symbol-plist was just
> workaround for lack of a better knowledge :). I stated that explicitly in the
> mail with the patch, but you perhaps didn't have time to read the mail?

I read all your mails carefully, and noted that there is no better alternative
than adding the window argument.

> Anyway, I understand now how is it done:
>
>       (append (eval (cadr (interactive-form 'Info-index)))
>               (list (selected-window)))
>
> I have to return a list of all arguments from interactive form; it was that
> simple. Thanks for the example.

Indeed, this is only an example.  More handling may be needed for
the return value of interactive-form.

>> Maybe it's possible even to write a macro that will generate
>> such wrapper commands automatically from existing commands.
>>
>> It seems you assume that all commands should take a window.
>
> Why would I assume that? I wrote explicitly which commands were extended with
> an optional window argument and why. I don't feel for repeating entire text 
> here,
> if you have interest, please take a look at the original email, you don't seem
> to have read it all. That mail answered your opening question, but I didn't 
> want
> to point it out earlier to not sound impolite, instead I tried to clarify the
> problems and choices further.

I was referring to your words from another mail that I read carefully:

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

I don't agree that all commands should be written with the assumption
that they can be called from any window.  Only commands with global
keybindings usually prepare the buffer with the predefined name and mode,
then mode-local keybindings and mode-local commands assume that they are
operating in the right buffer.

>> But there are no such assumption for most commands that work
>> only in the selected window.
>
> I am not sure what you are trying to say here. If we have several live buffers
> and wish to act on one, then the user has to choose one somehow, no? We can
> either try to automate stuff as I have tried in this patch, by prompting the
> user in ambigous case when system can't figure it on its own, or we can have 
> a 
> dumb system that forces user to *always* select a window prior to acting on a
> buffer. If you take a look at the original mail you will understand which 
> commands
> has got the optional window argument and why, but if you don't prompt the 
> user,
> than you don't need that argument at all.

Only commands with global keybindings need a way to select the right buffer.
The best example of such command is the entry point to the Info browser
the command 'info' bound globally to 'C-h i'.  This command allows the user
to select the right buffer "*info*<N>" by using the prefix arg.

What you are trying to do is to copy this logic to all Info-local commands.
And here comes the disagreement about the ways of doing this.

I know that you already said about this, so hereby I confirm that I already
have seen your opinion:

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

Replying to your opinion, I expressed a preference to avoid massive changes
in the existing functions.

> There is also a problem of prompting and input focus. As I wrote in response 
> to
> Eli, each command is its own little program, and can prompt user for whatever
> reason whenever. Thus each command should be written with the assumption that
> input should be presented to user on the frame where user types and with
> assumption that user is not executing it from the buffer/window on which it
> should act. You can achieve all this with tools already in Emacs, no need to
> introduce any new concepts or macros, and it will also work regardless of the
> window manager (I think).

I have no idea how this would work for window managers that don't switch focus
to the frame with the active minibuffer.

> It is just that the old commands are not written with those assumptions, so I
> rewrote Info commands in this patch. I am not sure you can achive that
> with wrapping, but perhaps there is a way, you can try.

Do you see some needs that can't be achieved with wrapping commands?

> In my opinion wrapping is OK if we for some reason can't alter the code, but 
> in
> the case of Info and help mode, I don't see such reason, especially since it 
> is
> possible to do everything backwards compatible. On the negative side,
> wrapping introduces double set of commands, so what are you saving? You are
> wrapping code from "outside", while I have done it from "inside", but overall,
> the principle is the same. On a plus side for wrappers is that you can 
> actually
> write a codegen for wrappers, hopefully in form of a macro and it will work 
> for
> other modes. So it is not only negatives, but you could also have both
> approaches at the same time too :).

Indeed, duplication of the command set is a drawback of wrapping commands.
OTOH, wrapping commands could be created mechanically, and they are very small.

So we have to decide what is worse: duplication of the command set,
or altering all existing commands by adding a new window argument to all of them
and making them more complicated.