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: Thu, 01 Jun 2023 19:39:58 +0300 Organization: LINKOV.NET Message-ID: <86mt1j16ht.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14149"; 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 Thu Jun 01 18:43:33 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 1q4lOf-0003XH-6o for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 18:43:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4lNw-0005mT-B8; Thu, 01 Jun 2023 12:42:48 -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 1q4lNu-0005gf-FG for emacs-devel@gnu.org; Thu, 01 Jun 2023 12:42:46 -0400 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4lNr-0000ea-DC for emacs-devel@gnu.org; Thu, 01 Jun 2023 12:42:46 -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 08FECE0006; Thu, 1 Jun 2023 16:42:38 +0000 (UTC) In-Reply-To: (Arthur Miller's message of "Thu, 01 Jun 2023 10:50:36 +0200") Received-SPF: pass client-ip=2001:4b98:dc4:8::224; envelope-from=juri@linkov.net; helo=relay4-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:306524 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. > Another problem with the above is that this will work only for 'other-window' > for which Emacs has an algorithm to figure out which window it is. But what when > you have more then two windows, and wish to switch to a different window than > what Emacs considers as 'other-window'? You will have to prompt the user, to > choose one. The help or info buffers are seldom the 'other-buffer' so constanly > choosing the window would be just as annoying as constantly switching to and > from, in my opinion. Indeed, which window to use is a separate question. 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. > I would prefer if there was a code gen in form of a macro, as suggested, similar > to define-minor-mode, that does this switching on pre-defined prefixes so that > we get uniformity, and helps people write commands so they work from > anywhere. Since it is not possible to completely automate it, perhaps lisp > manual could mention how to write commands so they are callable from other > windows then just selected one. The downside is that every command needs to be modified and its body wrapped with a macro. An alternative would be to put a new property on the command symbol with a function that selects a window to redirect input to. Implementation-wise this is like repeat-mode works. Additionally, this will allow making redirected keys repeatable like Manuel asked to do. Then: Currently: C-x o SPC SPC SPC DEL C-x o With a prefix before every key: C-h M-i SPC C-h M-i SPC C-h M-i SPC C-h M-i DEL or with a shorter prefix key: M-i SPC M-i SPC M-i SPC M-i DEL With repeatable key sequences: C-h M-i SPC SPC SPC DEL + some key to terminate the sequence of redirecting input to another window > I don't say you should not include the pre/post hack into Emacs if you want, it > is better then what already is there for the similar purpose (don't remember > longer the one included since I don't use it). I am just saying that we should > perhaps write better commands in the future, so we don't need the hack :). And I don't say that the pre/post approach is more reliable. There are other alternatives for general code to select a window before executing a command as opposed to modifying every command.