From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Control help- and Info-mode buffers from other buffers Date: Sat, 03 Jun 2023 18:15:49 +0300 Message-ID: <8335388tlm.fsf@gnu.org> 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> <83ilc48wx8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16762"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, 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 Sat Jun 03 17:15:54 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 1q5Syv-000494-Ug for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Jun 2023 17:15:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5Sy7-0008BO-Ar; Sat, 03 Jun 2023 11:15:03 -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 1q5Sy4-0008Ag-W4 for emacs-devel@gnu.org; Sat, 03 Jun 2023 11:15:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Sy3-0001fx-5Q; Sat, 03 Jun 2023 11:14:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sIW9ZYhG26jyDKzl828rsmnq7hfmKBtnYWa9c9pJZ8A=; b=F+Nl5Zb68nun npZ2ZA1jVFhpPB+TuumPw9ANrHRoBMYB566hVsEoW+4qy8zdL27NvswZ7G94EoAUfaa8lsoTQ95hL 6vS4K4sN+HGLup/WzHOL3kLU5xz47XdggSoac7FAtZHzsP/Efxo/hfJRPZF50UB0cqNSHwgPBxRSP /nINnno15PPTKqXYoghPlvmHjBLglmanUdn/cI7GrSl3bwEEawLub+6miSGWQ1hX75INcKdTf0sLU hSa4BjVOizCxv2U+TGTwnybD32ByI8WtXpcX0gUizfPF+8KiPIF4m1mIa/mqUJ2/rrAHYBZ1g3UQV uI9UzguP2+icSbPtIb4k7A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Sy2-0005Ch-Cv; Sat, 03 Jun 2023 11:14:58 -0400 In-Reply-To: (message from Arthur Miller on Sat, 03 Jun 2023 17:06:24 +0200) 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:306595 Archived-At: > From: Arthur Miller > Cc: juri@linkov.net, manuel@ledu-giraud.fr, emacs-devel@gnu.org > Date: Sat, 03 Jun 2023 17:06:24 +0200 > > Eli Zaretskii writes: > > >> From: Arthur Miller > >> Cc: juri@linkov.net, manuel@ledu-giraud.fr, emacs-devel@gnu.org > >> Date: Sat, 03 Jun 2023 15:53:22 +0200 > >> > >> The interactive form has to be the very first form in a function body, which > >> makes it impossible to just wrap the entire function into > >> with-selected-window. > > > > I still don't understand why you need the entire function to be > > wrapped in with-selected-window. > > Because part in the interactive form would like to do some work in the info buffer > too. Since we have called function from some other buffer it simply wont > work before switch to info buffer. Then use with-selected-window inside the interactive form. > > I don't understand: I thought we were talking about causing the other > > window to do something without the user selecting that window. So why > > does it matter where input goes? what input do you want to go to the > > non-selected window or frame? > > Yes we are; but some functions prompts user for additional input, and if the > info is in another frame but the one with the focus, than minibuffer does not > get the focus, and the input instead goes into the frame where mouse > cursor/point is. See more further down. I don't understand: prompts are in the minibuffer, so are you saying that there's some situation in Emacs when a Lisp program prompts the user, but the minibuffer with the prompts doesn't get input focus? That'd be a terrible bug in Emacs in general, not related to the issue we are discussing. Please report such a bug ASAP! > Not *Help*; I am asking about multiple *info* windows. A prefix arg should be able to solve at least some such problems.