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.
>
> With this code snippet:
>
> #+begin_src emacs-lisp
> (progn
>   (add-hook 'pre-command-hook
>             (lambda ()
>               (other-window 1)
>               (setq this-command (key-binding (this-command-keys)))))
>   (add-hook 'post-command-hook (lambda () (other-window -1))))
> #+end_src
>
> in 'emacs -Q' type: C-x 4 4 C-h i m emacs RET
>
> and it opens the Emacs Manual.

I tested now, and it did work. But I ended up with two info window? :)
I have started with two-window setup, info and scratch, left and right and I
think pre-commands created new window instead of selected the other window. You
can see in the screenshot, but other than that it worked.

three-window-help.png
Description: PNG image

> Then 'SPC SPC SPC DEL' scrolls it from the *scratch* buffer.

These are quite involved shortcuts. Think of people memorizing all that, and
typing all that. In case one would repeat commands, isn't it just less key
tapping to jumpt to window, do what is needed, and jump back. If we say
Info-mode-map is on a key (my peronal M-i), for me it becomes M-i j,
sequence of a one- or two-key combinations, and 'j' to jump back, regardless of
what Emacs considers other window. Even with repeat-mode I don't see if saves
much compared to just simply switching to the window? Or do I miss and
misuinderstand? I don't use repeat-mode, so I am not super sure about this.

I use pre/post hook as from that Reddit discussion, a lot, to find-file in other
window, to switch to previous/next buffer in other-window and similar, but these
are all "one-timers" relatively speaking. If I would to do something in
other-window, I would switch to that window. Might be just me and my workflow,
but I don't think it is important to stay in the same buffer at any price at all
times. To me doing stuff in other window, remotely in help, info, etc (I am
thinking of doing something similar with ielm and "working-buffer too") is just
a helper. If it becomes more cumbersome to execute stuff there, then it defeats
the purpose. The purpose is to make usage less cumbersome and minmize switching
between the windows which implicitly minimizes key pressing. That is just my
personal preferance and motivation; I understand that other people have other
worklfows, use-cases etc.

>>> 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.
>
> You can't avoid the need of customization even when using 
> with-selected-window.
> Since you have already seen requests to support renamed Help/Info buffers
> like "*info*<2>", Man-mode buffer names like "*Man ...*", support frames
> using the argument ALL-FRAMES of 'get-buffer-window', ...
>
>> 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?
>
> Help/Info commands could have this property by default, then users could
> add support for more commands by adding such a property to command symbols.
>
>> 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?
>
> The property could define a function that selects a window
> like in your code above.
>
>> 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.
>
> Indeed, the implementation that selects a window could be the same.

Could that function/implementation be made so that a highly hypothetical macro
say "define-command", calls it somehow instead of actually generating the code
in the user command? Otherwise it would be a lot of code duplication, which is
why you don't like with-selected-window I guess? I would like the effect as in
the above little piece of code, but not the exact implementation. And I would
like if C-u and C-u C-u where standardized to use this, instead of every
function usnig them in any way they like and prefixes being used wildly
differently across commands. I understand it is probably a controversial
suggestion :).