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: Thu, 01 Jun 2023 05:16:41 +0200 [thread overview]
Message-ID: <AM9PR09MB49771A772DFFBAAF8D12EEF696499@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <86wn0opgpi.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 31 May 2023 20:13:13 +0300")
Juri Linkov <juri@linkov.net> writes:
>>> since it would be nice to have a general function
>>> that will delegate key presses to any window,
>>
>> I think it is similar, but still a different problem then remotely executing
>> commands available in other buffer. To start with there is a nice trick
>> via pre/post command hooks, someone posted to me on Reddit:
>>
>> https://www.reddit.com/r/emacs/comments/x0r0pe/share_your_otherwindow_commands/
>
> A hook-based approach looks promising.
>
> When such simplest prototype that demonstrates this solution
> conceptually works well
>
> (progn
> (add-hook 'pre-command-hook (lambda () (other-window 1)))
> (add-hook 'post-command-hook (lambda () (other-window -1))))
>
> then it could be extended by adding customization, etc.
>
>> It works quite well in some cases, but not in all. For example it does not work
>> with Info-menu when invoked from other buffer either.
>
> If the code above doesn't work in all cases, this means we have a bug.
You are conceptually definitely correct :), but I believe that we are in this case
treating symptoms instead of the cause.
The reason we would like to send input to other-window (or any window) is to be
able to invoke some command in that window. Why can't we just invoke the command
directly, via M-x, when anything bound to a key is an interactive command by
definition? The reason is that commands are written with (or without) some
assumptions. The most notorius here is that many commands are written to act in
current buffer on selected window. It is not an unreasonable assumption, I am
just saying that commands are ordinary lisp code that can do anything, and
if they are not written with assumption to be run in some other buffer or
window, than there can be problems.I am not sure I would call it a bug, this was
just a natural assumption to make commands act on selected window and
current-buffer, but in certain cases, it is indeed a limitation, or perhaps
better to say, a noise, since it causes this extra switching between windows.
next prev parent reply other threads:[~2023-06-01 3:16 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 [this message]
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
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=AM9PR09MB49771A772DFFBAAF8D12EEF696499@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 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).