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: Sun, 04 Jun 2023 19:50:18 +0300 Organization: LINKOV.NET Message-ID: <86y1kzxorl.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> <834jnrek7w.fsf@gnu.org> <86v8g77iof.fsf@mail.linkov.net> <83o7lzcxm8.fsf@gnu.org> <837csncfz1.fsf@gnu.org> <83o7lybaph.fsf@gnu.org> <83ttvpao80.fsf@gnu.org> <86a5xfzllr.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="20231"; 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: Eli Zaretskii , manuel@ledu-giraud.fr, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 04 19:02:43 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 1q5r7r-00058a-28 for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Jun 2023 19:02:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5r6z-000728-4O; Sun, 04 Jun 2023 13:01:49 -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 1q5r6v-00071j-Oa for emacs-devel@gnu.org; Sun, 04 Jun 2023 13:01:45 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5r6s-0007ld-2R; Sun, 04 Jun 2023 13:01:44 -0400 X-GND-Sasl: juri@linkov.net 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 798E840002; Sun, 4 Jun 2023 17:01:38 +0000 (UTC) In-Reply-To: (Arthur Miller's message of "Sun, 04 Jun 2023 16:04:39 +0200") Received-SPF: pass client-ip=217.70.183.194; envelope-from=juri@linkov.net; helo=relay2-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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:306623 Archived-At: >> I think a good default would be to use the most recently used window. > > Isn't that what would Emacs does per automatic, I mean what get-buffer or > get-buffer-window chooses? The docstring of 'get-buffer-window' says nothing about this, only the Elisp manual provides the details: -- Function: get-buffer-window &optional buffer-or-name all-frames This function returns the first window displaying BUFFER-OR-NAME in the cyclic ordering of windows, starting from the selected window (*note Cyclic Window Ordering::). Then to return the most recently used window better to use 'get-buffer-window-list' and sort the list by recency. > As I got the idea yesterday while writing about it; It is possible to just work > in info-buffer, there is no need to also switch to window. The above interacitve > form is from Info-menu; and now I get the prompt displayed in the selected frame > not one with the *info* buffer and I can remove the ugly global var I used for > "the communication" too :). So you are using 'with-current-buffer'. But what if the same Info buffer is displayed in two windows? What point will you get after visiting the Info buffer with 'with-current-buffer'? It will use the window point from the first Info window or from the second Info window? The preference will be according to the cyclic ordering of windows, or the most recently used window?