From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Systematizing back navigation Date: Tue, 21 Nov 2023 13:15:42 +0000 Message-ID: <87learjlhd.fsf@catern.com> References: <87il5vixat.fsf.ref@yahoo.com> <87il5vixat.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:f3QiyPB/hurd3mKagtxkq7/IQGY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 21 14:45:59 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 1r5R4h-0004Z8-KC for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Nov 2023 14:45:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5R3z-0008RU-2d; Tue, 21 Nov 2023 08:45:15 -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 1r5Qbs-00009q-84 for emacs-devel@gnu.org; Tue, 21 Nov 2023 08:16:13 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5Qbq-0001gX-1l for emacs-devel@gnu.org; Tue, 21 Nov 2023 08:16:11 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r5Qbl-0005f4-B9 for emacs-devel@gnu.org; Tue, 21 Nov 2023 14:16:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 21 Nov 2023 08:45:04 -0500 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:313111 Archived-At: Po Lu writes: > 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. In the first instance, this calls for a unified undo system which > preserves changes to the window configuration, that they might be > reverted when Back is pressed. > > 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. This sounds like a very interesting and useful system! I would love to have a single key which handles all the different forms of going back, including xref-go-back and others. This is also a very familiar mode of interaction from web browsers, using back and forward to navigate across different web sites with different content and different applications, not just within one application. Thought: Could we also support "go forward"? That would make it more clear that this is not just an Android thing. And forward navigations is supported by all these individual things, e.g.: - Info-history-forward - help-go-forward - xref-go-forward - winner-redo Thought: Supporting xref-go-back will mean that "go back" might just move to a different position within the current buffer rather than necessarily changing buffer or buffer contents. Thought: global-mark-ring might be part of a universal go-back button. > There are two shortcomings to this I can't yet address. If window > configurations are saved, then the selected window is also accounted a > navigation operation and is subject to change when Back is pressed. It looks like, from some brief experimentation, that winner-mode doesn't save the selected window. Maybe you can do whatever winner-mode is doing? But also, I'm not actually sure this is a shortcoming. It seems like changing selected window might be desirable behavior. See below. > Not 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. I think we should limit Back to a single tab/frame, not to a single window. I think in practice that would be what we'd want. In environments like GNOME/KDE/Windows/MacOS/Android, each application runs in its own window, and a "Back" button (if the application provides it) will operate on that individual window. Those environments might let you display two applications next to each other, in two separate windows, and the Back button will still operate on the individual application. But in Emacs, there isn't a one-to-one relationship between "window" and "application". Emacs packages make a lot of use of multi-window behavior. For example, xref pops up a window with matches, and gnus makes various multi-window layouts. So it makes sense for the Back button to operate on an entire window configuration, within a specific tab or frame. And if a user wants to have two "applications", like gnus and text editing, and have Back operate only on one at a time, they can use two tabs. If the user wants gnus and editing buffers displayed next to each other, they can put two frames next to each other. (It would be kind of nice to have a uniform way to subdivide a frame so that gnus didn't take over the entire frame; if we had such a way to subdivide the frame, then maybe Back would operate on that unit. But that's for the future)