From: Juri Linkov <juri@linkov.net>
To: Arthur Miller <arthur.miller@live.com>
Cc: Manuel Giraud <manuel@ledu-giraud.fr>, emacs-devel@gnu.org
Subject: Re: Control help- and Info-mode buffers from other buffers
Date: Fri, 02 Jun 2023 09:32:22 +0300 [thread overview]
Message-ID: <86zg5i1ku9.fsf@mail.linkov.net> (raw)
In-Reply-To: <AM9PR09MB4977412B16D8387A810A0713964EA@AM9PR09MB4977.eurprd09.prod.outlook.com> (Arthur Miller's message of "Fri, 02 Jun 2023 03:10:41 +0200")
>>> 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.
Then 'SPC SPC SPC DEL' scrolls it from the *scratch* buffer.
>> 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.
next prev parent reply other threads:[~2023-06-02 6:32 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 [this message]
2023-06-04 14:41 ` Arthur Miller
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86zg5i1ku9.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=arthur.miller@live.com \
--cc=emacs-devel@gnu.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).