From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Control help- and Info-mode buffers from other buffers Date: Fri, 02 Jun 2023 09:32:22 +0300 Organization: LINKOV.NET Message-ID: <86zg5i1ku9.fsf@mail.linkov.net> References: <87h6ruf09e.fsf@ledu-giraud.fr> <861qixbum2.fsf@mail.linkov.net> <86wn0opgpi.fsf@mail.linkov.net> <86ilc78zc2.fsf@mail.linkov.net> <86mt1j16ht.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31339"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: Manuel Giraud , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 02 09:06:37 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q4yrs-0007uV-0T for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Jun 2023 09:06:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4yqn-0005Je-Be; Fri, 02 Jun 2023 03:05:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4yqi-0005CZ-TB for emacs-devel@gnu.org; Fri, 02 Jun 2023 03:05:25 -0400 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4yqe-00083n-EO for emacs-devel@gnu.org; Fri, 02 Jun 2023 03:05:24 -0400 X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 00F5EC000C; Fri, 2 Jun 2023 07:05:13 +0000 (UTC) In-Reply-To: (Arthur Miller's message of "Fri, 02 Jun 2023 03:10:41 +0200") Received-SPF: pass client-ip=217.70.183.198; envelope-from=juri@linkov.net; helo=relay6-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306543 Archived-At: >>> 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.