unofficial mirror of emacs-devel@gnu.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: Wed, 31 May 2023 07:55:31 +0200	[thread overview]
Message-ID: <AM9PR09MB49773EA3E140E18686DFA76696489@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <861qixbum2.fsf@mail.linkov.net> (Juri Linkov's message of "Tue,  30 May 2023 20:29:20 +0300")

Juri Linkov <juri@linkov.net> writes:

>> I have actually tried to find some general way to do this
>> programmatically with any buffer, but thus far, I don't see any
>> general way that is both efficient and 100% failsafe.
>
> Please share your experience what have you tried

Hi Juri;

I have tried several quite different things, so that would be quite a long mail
:-).

In that particular place, I am actually referring to something different
then what you think of, I believe. As I wrote to Manuel, I was basically doing
programmatic what I have done manually with the patch. Problem with the programmatic way
was too much processing, and some functions didn't work. The former could be
perhaps helped by using a macro to do it at compile time, and the latter is
perhaps lack of lisp-fu on my side. I don't know, but the idea was to advise the
already prefixed commands in a mode-map, and to generate new commands for those
that are not prefixed. The advice switches to the buffer, executes the original
commands, and switches back. Something like this (just the advising and generation part):

#+begin_src emacs-lisp
(defun remote--make-advice-body (buffer-name)
  "Create lambda function for buffer with name BUFFER-NAME."
  #'(lambda (fn &rest args)
      (let ((previous (selected-window))
            (buffer (get-buffer buffer-name))
            (window (get-buffer-window buffer-name)))
        (unwind-protect
            (when (get-buffer buffer)
              (unless (window-live-p window)
                (display-buffer buffer))
              (select-window window)
              (apply #'call-interactively fn args))
          (select-window previous)))))

(defun remote--make-advice-function (buffer-name)
  "Create advice function for buffer with name BUFFER-NAME."
  (let ((advice-name
         (intern (format "help-remote--%s-advice-fn" buffer-name))))
    (unless (fboundp advice-name)
      (defalias advice-name (remote--make-advice-body buffer-name)))
    advice-name))

(defun remote--advise (fn buffer-name advised)
  "Advice function FN to run in buffer with name BUFFER-NAME."
  (let ((advice (remote--make-advice-function buffer-name)))
    (add-to-list advised (cons fn advice))
    (advice-add fn :around advice)))

(defun remote--gen-cons (binding prefix buffer-name advised)
  "Ensure BINDING in buffer named BUFFER-NAME uses symbol prefixed with PREFIX."
  (let ((name (symbol-name (cdr binding)))
        (symb (cdr binding)))
    (unless (string-match-p prefix name)
      (setq symb (intern (concat prefix name)))
      (defalias symb (symbol-function (cdr binding))))
    (remote--advise symb buffer-name advised)
    (cons (car binding) symb)))
#+end_src

However I was not able to trick Emacs to trust me
its executing in the "correct" environment. Also, there was too much
processing in info mode. Some methods worked well; for example everything in
help-mode, but some functions that asks for user input in info-mode, for example
info-menu, didn't work at all.

> 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/

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.

> not just the hard-coded *Help* and *Info*.

I understand  your sentiment, and I agree that it might be useful to have
a way to delegate input to other window, but I also think we would still like
to wrap such generic command into some hard-coded cases to save typing. For
example in case of generic command and multiple windows, you will have to ask
user which window to execute in. In order to save that prompting and additional
typing on user part, it is handy to hard code such generic function to certain
cases like help and info here.

To shorten, I haven't found a good way to delegate input to other windows and I
am not sure if it will even work as a general idea at all. Perhaps for some
cases, it would work, but not for all. I am inclined to believe that this is the
wrong side to attack the problem. Perhaps it is better to write commands that
are aware that they could be executed from other buffers than the one they act on?
In that case command could prompt the user for a window or buffer to act on and
auto switch to that window and back. Since the command usually knows which mode
it belongs, it could even filter out windows/buffer that does not have that
mode activated, or some other feature it requires. It would be relatively simple
to implement with prefix-argument?

But perhaps I am wrong too. Perhaps  you have something different? :)




  reply	other threads:[~2023-05-31  5:55 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 [this message]
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
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=AM9PR09MB49773EA3E140E18686DFA76696489@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).