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: Thu, 01 Jun 2023 19:19:47 +0300 Message-ID: <837csncfz1.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10189"; 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 Thu Jun 01 18:20:09 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 1q4l21-0002Ta-H9 for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 18:20:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4l16-0000Ia-ND; Thu, 01 Jun 2023 12:19:12 -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 1q4l0x-0000BJ-2U for emacs-devel@gnu.org; Thu, 01 Jun 2023 12:19:05 -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 1q4l0u-0004hM-U5; Thu, 01 Jun 2023 12:19:00 -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=L577apSq27Oc48Dz07/6zjkEZsTNX+BuTQo//EY+XE0=; b=mAtJjMmA80rL vHPGrZHEruiuAQTwOSvma2kPRzRWdpyf3RRjOHhb1wp6zV5f9DvaXygWuQ2QxXyizsbnVccZQV5Ja IqA8xFs/iPUWuAkI0frTPCrdkIT+Nverz58V1U5ZpLIbatfv0bEbMcIrETM3jk358JDQA3m9lQ3nd tYPsxtPYigDTChg6RKzk8wTbqb1lrBjK0/QWEVVd4r8RjGgC9P82ILqGmNcxxAemUBeoJHzjslWPw Vd9cIavwKhOzi4RXly4joiU2S91pfHXOgarMxiwzxSO36RxHY8QkM99U54T24ZR4Ci9RIjX82+mYV PSsl0LTxIFlUlmXn4hG5Fg==; 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 1q4l0u-0000cJ-Ds; Thu, 01 Jun 2023 12:19:00 -0400 In-Reply-To: (message from Arthur Miller on Thu, 01 Jun 2023 15:45:53 +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:306522 Archived-At: > From: Arthur Miller > Cc: juri@linkov.net, manuel@ledu-giraud.fr, emacs-devel@gnu.org > Date: Thu, 01 Jun 2023 15:45:53 +0200 > > If I try to illustrate with an example: consider a two-window setup with scratch > buffer in first and info buffer in second window. If presses a key to execute > next command in other window and then 'm'the system will choose commands from > selected window (self-insert command in scratch buffer) and try to execute that > command in other window which is info buffer. Tbat is obviously wrong since user > probably meant to execute Info-menu, by default bound to 'm' in Info-mode. > > I don't know if that can be fixed by perhaps manipulating unrread-key-events > list or in some other way, perhaps by putting input key back, or by some other > means. I haven't managed to get it correctly and have given up and instead tre > to address the problem in more fundamental way by making those functions aware > of the context they execute in. Also, even if problems could be fixed, I see no > point of using such method in this particular patch. 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... and then we need to bind it to, say, "C-x 4 h m". Did I miss something important? > But for the suggested patch for help and info, I see no reason to use pre/post > hook to switch windows, I can just use with-selected-window which does > exactly the same switching for me in 90% of cases, and manually fix the few > cases which needed some extra care. I didn't say anything about any hooks. > For example what happends if a command call > another command and it happen to have post hooks? Will it run after the second > command call internally (I think it will), which means it will switch back to > old window prematurely. Any post-command-hook should be prepared to deal with commands that switch buffers and windows, so I see no new problems here.