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: Fri, 02 Jun 2023 10:11:06 +0300 Message-ID: <83o7lybaph.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13056"; 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 Fri Jun 02 09:10:56 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 1q4yw4-0003Cp-D6 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Jun 2023 09:10:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4yvh-0008BP-6H; Fri, 02 Jun 2023 03:10:33 -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 1q4yvU-00087K-MW for emacs-devel@gnu.org; Fri, 02 Jun 2023 03:10:21 -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 1q4yvT-00028D-JM; Fri, 02 Jun 2023 03:10:19 -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=5FUNXSKgaeMkOM4Vv0DArThdpMa0mCK6zRazqn3brqM=; b=lfDicKD2x/g+ YeJw3arITf3VsusQPsAXFiZy3Vh9Y/tWphGFw81W+SJAc543wt3IEqkKAtRPU7qso7EjG2vh6jfLU 23dY4AEqmf3l7mgP8hALuGrqCfgJ0IVwRA2kUmw/u9Y717LzaiD8SePCK0cxxQFaKbRzWL2YeqK/i 0GHkuKDkI7cDBh8qWaVkFxMq/uGdoyoJpNjzlzFDDQtaASgyEPI9SlGA5owZuUloIfHAX9dcOtCWk eoXmHh5wlFpHthr1uGyCNoYESLfvwJG0sgooCpjeuWXbuYm1lBR+8r0y68BF3w4+XoubiwQKmJFRq ENDDx36qj40xwo7EQfi28w==; 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 1q4yvT-0001tb-2m; Fri, 02 Jun 2023 03:10:19 -0400 In-Reply-To: (message from Arthur Miller on Fri, 02 Jun 2023 03:26:26 +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:306544 Archived-At: > From: Arthur Miller > Cc: juri@linkov.net, manuel@ledu-giraud.fr, emacs-devel@gnu.org > Date: Fri, 02 Jun 2023 03:26:26 +0200 > > > I don't understand why you see such complexity. All we need is a > > command that will do > > > > (with-selected-window (get-buffer-window "*info*") > > BODY... > No you need a bit more than that sometimes. In case that interactive is doing > some prompting and buffer dependent setup, you will have to wrap interactive > body for itself, and function body for itself. See Info-mode or Info-find (I > think) in patch, but conceptually, yes that is about it. If you can live with > wrapping commands in with-selected-window. Due to fact that interactive form > must be the first form in a function body. You also have call-interactively, which can work around this minor obstacle. > > and then we need to bind it to, say, "C-x 4 h m". Did I miss > > something important? > > Basically that these were two discussions, one where Juri asked me about my > experiences about running commands in other windows, and one about the > patch. Juri dislike the idea of wrapping all commands into with-selected-window > and is trying to find a way to transfer command execution to other window > without need to wrap commands explicitly as I understand him, which I hope he > will find. Well, I see no reason to dislike what Juri dislikes in this case. So now you get to choose whose preferences you want to follow ;-) > The above is discussion about that general command that will send input > to other windows. As I said elsewhere in this thread, trying to make this more general than it needs to be is over-engineering. Not all commands can naturally be used with the "other-window prefix", and we are talking about help-related commands here. For help-related commands, it is natural to work in another window while having the help displayed nearby, and it is therefore natural to control that non-selected help window without having to select it first. So that is what we should do, IMO.