all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Juri Linkov <juri@linkov.net>
Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  emacs-devel@gnu.org
Subject: Re: Control help- and Info-mode buffers from other buffers
Date: Sun, 04 Jun 2023 16:41:27 +0200	[thread overview]
Message-ID: <AM9PR09MB4977C627BFC905FC9FFFB886964CA@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <86zg5i1ku9.fsf@mail.linkov.net> (Juri Linkov's message of "Fri,  02 Jun 2023 09:32:22 +0300")

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

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.


[-- Attachment #2: three-window-help.png --]
[-- Type: image/png, Size: 881695 bytes --]

[-- Attachment #3: Type: text/plain, Size: 5474 bytes --]



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

  reply	other threads:[~2023-06-04 14:41 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30  5:38 Control help- and Info-mode buffers from other buffers Arthur Miller
2023-05-30 12:54 ` Manuel Giraud via Emacs development discussions.
2023-05-30 13:31   ` Arthur Miller
2023-05-30 15:22     ` Manuel Giraud via Emacs development discussions.
2023-05-30 17:29     ` Juri Linkov
2023-05-31  5:55       ` Arthur Miller
2023-05-31 17:13         ` Juri Linkov
2023-06-01  3:16           ` Arthur Miller
2023-06-01  6:35             ` Juri Linkov
2023-06-01  7:05               ` Eli Zaretskii
2023-06-01  7:20                 ` Juri Linkov
2023-06-01  9:03                   ` Arthur Miller
2023-06-01  9:55                     ` Eli Zaretskii
2023-06-01 14:01                       ` Arthur Miller
2023-06-01  9:16                   ` Arthur Miller
2023-06-01  9:58                     ` Eli Zaretskii
2023-06-01 13:45                       ` Arthur Miller
2023-06-01 16:19                         ` Eli Zaretskii
2023-06-02  1:26                           ` Arthur Miller
2023-06-02  6:34                             ` Juri Linkov
2023-06-02 15:11                               ` Arthur Miller
2023-06-02 15:29                               ` Yuri Khan
2023-06-02 16:32                                 ` Juri Linkov
2023-06-04 14:09                                   ` Arthur Miller
2023-06-02  7:11                             ` Eli Zaretskii
2023-06-02 15:09                               ` Arthur Miller
2023-06-02 15:16                                 ` Eli Zaretskii
2023-06-03 13:53                                   ` Arthur Miller
2023-06-03 14:04                                     ` Eli Zaretskii
2023-06-03 15:06                                       ` Arthur Miller
2023-06-03 15:15                                         ` Eli Zaretskii
2023-06-04 14:19                                           ` Arthur Miller
2023-06-04 14:33                                             ` Eli Zaretskii
2023-06-04  7:52                                     ` Juri Linkov
2023-06-04 14:04                                       ` Arthur Miller
2023-06-04 16:50                                         ` Juri Linkov
2023-06-02 16:13                                 ` Juri Linkov
2023-06-03 13:49                                   ` Manuel Giraud via Emacs development discussions.
2023-06-04  7:44                                     ` Juri Linkov
2023-06-04  8:50                                       ` Eli Zaretskii
2023-06-04 13:40                                         ` [External] : " Drew Adams
2023-06-04 13:53                                           ` Arthur Miller
2023-06-04 14:00                                             ` Drew Adams
2023-06-04 14:20                                           ` Eli Zaretskii
2023-06-04 13:38                                       ` Manuel Giraud via Emacs development discussions.
2023-06-04  7:48                                   ` Juri Linkov
2023-06-01  8:50               ` Arthur Miller
2023-06-01 10:04                 ` Eli Zaretskii
2023-06-01 11:33                   ` Arthur Miller
2023-06-01 16:39                 ` Juri Linkov
2023-06-01 19:15                   ` Eli Zaretskii
2023-06-02  1:10                   ` Arthur Miller
2023-06-02  6:32                     ` Juri Linkov
2023-06-04 14:41                       ` Arthur Miller [this message]
2023-06-04 16:54                         ` Juri Linkov
2023-06-01  6:31           ` Juri Linkov
2023-05-30 16:15 ` Eli Zaretskii
2023-05-31  6:38   ` Arthur Miller
2023-05-30 18:04 ` [External] : " Drew Adams
2023-05-31  6:06   ` Arthur Miller
2023-05-31 13:00     ` Drew Adams
2023-05-31 13:27       ` Arthur Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM9PR09MB4977C627BFC905FC9FFFB886964CA@AM9PR09MB4977.eurprd09.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=manuel@ledu-giraud.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.