Re: Control help- and Info-mode buffers from other buffers

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>> Anyway, pre/post hook hack is very useful, and works with many commands, but 
>> not
>> with all, so it is not 100% failsafe and general.Try to execute Info-mode
>> from other window but Info (shortcut 'm'). In my Emacs it does not work.
>
> I tried 'm' (Info-menu), and it works nicely without any problem.
> As long as key prefixes are the same in both windows.

Ok. Then perhaps I am doing something wrong? How do you run it, is the posted
code snippet all you use, or is there something else there? For me it does not
work at all.

>> Another problem with the above is that this will work only for 'other-window'
>> for which Emacs has an algorithm to figure out which window it is. But what 
>> when
>> you have more then two windows, and wish to switch to a different window than
>> what Emacs considers as 'other-window'? You will have to prompt the user, to
>> choose one. The help or info buffers are seldom the 'other-buffer' so 
>> constanly
>> choosing the window would be just as annoying as constantly switching to and
>> from, in my opinion.
>
> Indeed, which window to use is a separate question.
>
> For the existing commands scroll-other-window, scroll-other-window-down,
> recenter-other-window, beginning-of-buffer-other-window,
> end-of-buffer-other-window, the user option that defines which window to use
> is 'other-window-scroll-default', and it can be customized
> to any function, for example, a function that looks for
> a window with a Help/Info buffer on the current frame,
> or on any other frame.  Or to a function that uses
> 'get-mru-window' to get the most recently used/displayed window.
> All this is customizable.

Sure it is, but is isn't a customization problem. We wouldn't like to customize
the stuff before every run, right? In a case like this, where we wish to run in
a specific window like help, info or perhaps working-buffer window in case of
ielm, we do want to make some specific commands, which means we would like to
wrap that general do-in-X-window command. Otherwise it would be annoying to
every time have to choose help window.

>> I would prefer if there was a code gen in form of a macro, as suggested, 
>> similar
>> to define-minor-mode, that does this switching on pre-defined prefixes so 
>> that
>> we get uniformity, and helps people write commands so they work from
>> anywhere. Since it is not possible to completely automate it, perhaps lisp
>> manual could mention how to write commands so they are callable from other
>> windows then just selected one.
>
> The downside is that every command needs to be modified and its body
> wrapped with a macro.

And for some commands, which use more complicated interactive form, it has to be
done separately for the body of interactive form and for the functon body, since
you can't wrap interactive itself in anything (it has to be first form in
function body), so yes indeed.

It would be a ginormous janitor work to go through all Emacs commands and
re-write them. I don't think it is even possible. So no I don't suggest that
:). I suggest this only for writing new commands, and I give a rough sketch as
an illustration of what I men:

#+begin_src emacs-lisp
(defun test-command (arg &optional kill window)
  (interactive "P")
  (let* ((window-alist (mapcar (lambda (w) (cons (format "%s" w) w)) 
(window-list)))
         (window
          (cond
           ((equal arg '(4))
            (other-window-for-scrolling))
           ((equal arg '(16))
            (cdr (assoc (completing-read
                         "Window: " window-alist) window-alist)))
           (t (window-normalize-window window)))))
    (with-selected-window window
      (message "Did someting in window: %s" window))))
#+end_src

The let* wrapp could be generated on part of the user, in some way.

>                        An alternative would be to put a new property
> on the command symbol with a function that selects a window to redirect
> input to.  

How are that property and function meant to be implemented? By the end user, or
by the Emacs? Can end user just choose something like :run-in (one of nil, t,
foo-mode, bar-mode, (some-predicate-p) some-function, etc), where "run-in" is
the property you suggest, and the rest are constrains to choose from?

I don't tink it is too much different from what I suggest, tbh, since it will
anyway have to select somehow the window and that selection would probably be
steared by some argument to the command, but it will be coded differently.