Re: Info-mode patch

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>> Also I didn't wanted to change API. Not that I believe that there are many 
>> 3rd
>> party packages for Info and Help modes, and that people actually customize
>> those, but anyway. Wrappers would be a new API, which all require at least 
>> some
>> documentation etc.
>
> Actually adding new arguments to existing functions counts as changing API.
Yes, but I have added just an optional argument at the end which shouldn't break
anything, right? I ment to document 'window' in the function doc but I forgott,
remembered after your mail last night :).

> Whereas not changing existing functions means keeping the current API 
> unchanged.
> Since you need to bind commands to new keys anyway, there is no difference
> whether you bind old commands or new other-window commands.
I have introduced four new commands where I couldn't do otherwise. But I didn't
want to duplicate all commands by wrapping. There is problem of documentation, 
people
wondering why they are duplicate similar functions, more commands in Emacs, and
in non-trivial examples it is not possible to just "wrap" stuff in
with-selected-window anyway. I think doing it properly from the beginning and
adapting stuff under the hood without changing the API or visible commands is a
better alternative.

>> Can you control on which frame the input goes when prompted by original
>> function with a wrapper approach? I changed quite few prompts a wrapped stuff
>> with both with-current-buffer, and with-selected-frame to achive that. I 
>> don't
>> think I could do that if I wrapped stuff. But what do I know, perhaps there 
>> is
>> some way?
>
> I see that you added with-selected-frame to Info-index.
> 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. The reasoning was like this:

There are (possibly) two frames: "the user frame", one whith some other buffer 
and
possibly on other frame than info, and "the info frame". We need to switch
potential prompts that ask user for the input from info frame to the user frame,
and execute the effects of the command on info buffer. We don't want to switch
frames and user selected window, that is the point of the patch. If user wish to
switch to info frame, they can do so already, as they would do pre-patch. At
least that was my reasoning for the patch. 

> Since neither with-selected-window nor with-selected-frame
> can switch focus, we could add a new macro like
>
> #+begin_src emacs-lisp
> (defmacro with-selected-window-frame (window &rest body)
>   `(let ((frame (window-frame ,window)))
>      (unless (eq frame (selected-frame))
>        (select-frame frame 'norecord)
>        (select-frame-set-input-focus frame 'norecord))
>      (with-selected-window ,window
>        ,@body)))
> #+end_src
>
>
> Then everything works nicely with

Have you tested *everything*? Interactively and from lisp?

> #+begin_src emacs-lisp
> (defun Info-index-other-window (topic)
>   (interactive (with-selected-window-frame (info-window)
>                 (eval (cadr (interactive-form 'Info-index)))))
>   (with-selected-window-frame (info-window)
>    (Info-index topic)))
> #+end_src

That would be a different behaviour for *all commands* if you would to apply
that macro to all commands consistently, but I don't think that is what you
would want. In the end, I think you still have to go through each and every
command and do something different on the basis if you want to switch window
focus or not.

Otherwise, if you gonna leave focus in info window, then just introduce a simple
way to switch to info window, as I did with the "Info-jump" which I have removed
in this patch. I think the reasons to jump over are less due to being able to
create "connection" to an info window and use that as the default, without the 
need to prompt the user or type the numeric prefix. It also works with window
created via "C-1/u m" which creates names based on chosen node for visit, for
example *info-Elisp* instead of *info<N>.

Notice that select-frame-set-input-focus won't move the mouse cursor, which
means that mouse will possible (not necessary) be left on the old frame. If a
user has, like I did, enabled "focus follow cursor" than depending on the window
manager user has, Emacs will be fighting for focus with the wm. Not all managers
respect X11 hints  and requests.

Perhaps, you could save the frame that has the mouse cursor underneath and
restore it afterwards too when needed, or warp mouse just somewhere into the
info frame, and restore the position afterwards, but I wouldn't bother, that
sounds like more troubles then worth.