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: Systematizing back navigation Date: Tue, 21 Nov 2023 07:35:24 +0200 Message-ID: <70ABA96C-74EE-40B2-BB0F-A0FDAA412BE7@gnu.org> References: <87il5vixat.fsf.ref@yahoo.com> <87il5vixat.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31287"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android To: emacs-devel@gnu.org, Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 21 06:36:03 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 1r5JQY-0007uR-Se for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Nov 2023 06:36:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5JQ4-00056H-1s; Tue, 21 Nov 2023 00:35:32 -0500 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 1r5JQ2-00054K-BA for emacs-devel@gnu.org; Tue, 21 Nov 2023 00:35:30 -0500 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 1r5JQ2-0003V8-1I; Tue, 21 Nov 2023 00:35:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=y9zcalBsnlOdLHAooLvWhKabyuLMPBCPEo9L+rY9o2I=; b=iPYJvKUzdAZ7p7mfbeeO 5+gDlG8N9uwf5X03faU1FvVwy9o0gCe0pEiqSEUPVITEMUbxKICIiUL6EJ7M4G+n7+6FYUcWq8yE0 bMxBT17ueFfxyH4+cq0XJYI8Ba0MpYuh7kV6DVvGL0vKQ5JLTOMk5QcHGsfxg+nSqqH7BS6tpuZFM 0a1YCMfTRitCuDbodgmDylG0WsaUBcLpvsXtM9gHnYV2MEFHHcPcpFgV6Oo9surBHUmUeF1eVVqJS mYpEsTpws9zmeI/UthMVc/nEYXpTLeYRgXAPWL8xkqIsBMGJXIWq/4Meqo1DBfSWtxjBFl1MAbZ7z ubFuiiw2esMt0A==; In-Reply-To: <87il5vixat.fsf@yahoo.com> Autocrypt: addr=eliz@gnu.org; keydata= mQENBF+pf4UBCAC6vjkWLSAsQpe8YIGKLQzNOJx/IjGtCdFF8uzmO5jmME+SD8ROuJN+t5KXVw58 uzu75EFD0vHTY9e+udJ2gkpuy0NnzkFcbumdLLo2ERKCoSctZZRhzKXI5z5cHxCqW0B2ygHRrRLt oNlGID7bAgcgSViT1ptGqTXO7zGVu4Airok7dNzcPtHgns8GlR5YAFX0TvE6oGd0l2VPghNeVJKJ OjrbfhoDxl3ucFpqbqMH8z9HTLDOFpz8UaYYUdJMi3xX6vwTZxI2sM2RRVLUpZyllAkSMI4lln1O OgazM/62DJUs/rKIHKBnF6h3/qsJUjUYXaAHbrXY26mWllAd536lABEBAAG0I0VsaSBaYXJldHNr aWkgKGVsaXopIDxlbGl6QGdudS5vcmc+iQE4BBMBAgAiBQJfqX+FAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAAKCRCRwSYvAeuNOYUQB/4/iIKKOG45ijNaRoTvmJJZMvj1S07WQxEm7c5SHEeE QbLOAxB9vESOV7sLueuN3oqEndtzyYt4x1WTSBmHFF7h5fcCMjBs41siOIp5Sj/xD0Bvaa0IKGCR SZ7PAo8Mq3wgajXpTpn9vxE2PmtzA8KdEE0K1+f9pVAfOpUIcCl44rIxLUW352XG0y7iz6c/O6LB 1deOKMiKFctKO7pBti1dJEm1ImewLH3H8uTbwspLOs3EB8xhsESxmTidnze68HX2jt+2EeMgCdki NU+LWbexQZPfIS7+ZmE06ll0v6+Jy7ZdTkCCRypKWTnW7pIFsq/p4kybV8O/kHSV6B4vvQBfuQEN BF 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:313092 Archived-At: On November 21, 2023 5:45:46 AM GMT+02:00, Po Lu wro= te: > There is presently a bewildering set of actions taken in response to an > XF86Back key press=2E In most buffers, it is equivalent to typing C-x > , switching to the buffer previously displayed in the current > window=2E In Help buffers, it navigates to the last Help notice > displayed, and in Info buffers, it navigates to the last node displayed= =2E >=20 > Such behavior is confusing because XF86Back cannot be relied on to > restore an earlier state of affairs, be that a previous window > configuration, Info node or current buffer=2E To give an example, if th= e > Info directory is opened, then the node "(elisp)Numeric Conversions", > the scratch buffer, and the Info buffer once more, XF86Back will return > to the Info directory instead of *scratch*=2E If XF86Back is pressed > thereafter, Info will print a message to the effect that there is no > previous node in the Info buffer's history without restoring any earlier > window configuration=2E >=20 > Moreover, restoring merely the last buffer to have been selected does > not suffice at times: when I press Back after typing "F" in a Gnus > Article buffer displays a message buffer occupying the whole frame, I am > brought to the Summary buffer, while it is the previous window > configuration incorporating both the Summary and Article buffers that > should be restored in this case=2E >=20 > The object of such keys as XF86Back and its Android analogs is to undo > the effects of the last navigation: a call to display-buffer, switching > to a different window, clicking on a link in an Info buffer, and the > like=2E In the first instance, this calls for a unified undo system whi= ch > preserves changes to the window configuration, that they might be > reverted when Back is pressed=2E >=20 > As this cannot account for forms of navigation that spare the window > configuration, Info and Help buffers must also make a note of new nodes > visited within this undo system and supply means by which these > alterations can be undone=2E >=20 > There are two shortcomings to this I can't yet address=2E If window > configurations are saved, then the selected window is also accounted a > navigation operation and is subject to change when Back is pressed=2E N= ot > only is this unwanted, it also impedes addressing the second > shortcoming, which is that it ought to be possible for the effect of > Back to be limited to a single window, such as by restoring the selected > buffer of that single window rather than that of the window whose > selected buffer is the last to have changed=2E >=20 > Thus instead of implementing and installing a prototype of this at a > venture, I want to ask everyone else's advice, and also for ideas as > regards when and whether this Back mechanism should act as described in > the last paragraph=2E >=20 > TIA=2E >=20 >=20 I think you are over-engineering this=2E That a key has different binding= s in different major modes is nothing new in Emacs=2E Moreover, smartphone= apps are also inconsistent in what the Back button does in each situation= =2E So I don't see why we need to worry about this, let alone pretend there's = some deep internal issue here=2E Perhaps you bumped into some specific sit= uation, and then tried to generalize it too much=2E In that case, I sugges= t to describe the original issue, not its generalizations=2E Thanks=2E