From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#59381: Should xref--marker-ring be per-window? Date: Mon, 21 Nov 2022 01:17:02 +0200 Message-ID: References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22552"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 21 00:18:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1owtZp-0005hd-Ik for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Nov 2022 00:18:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owtZd-0006P3-Mc; Sun, 20 Nov 2022 18:18:05 -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 1owtZa-0006Oo-Ek for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 18:18:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owtZa-0000x6-6S for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 18:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1owtZZ-0007Yd-Pd for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 18:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2022 23:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59381 X-GNU-PR-Package: emacs Original-Received: via spool by 59381-submit@debbugs.gnu.org id=B59381.166898623828999 (code B ref 59381); Sun, 20 Nov 2022 23:18:01 +0000 Original-Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 23:17:18 +0000 Original-Received: from localhost ([127.0.0.1]:44891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owtYr-0007Xf-Hv for submit@debbugs.gnu.org; Sun, 20 Nov 2022 18:17:17 -0500 Original-Received: from mail-wm1-f47.google.com ([209.85.128.47]:34581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owtYl-0007XM-Ko for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 18:17:16 -0500 Original-Received: by mail-wm1-f47.google.com with SMTP id t25-20020a1c7719000000b003cfa34ea516so9413176wmi.1 for <59381@debbugs.gnu.org>; Sun, 20 Nov 2022 15:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=raply1yZdwY0rTLYnBKwC+I+8boUM+ePSGAk/7SxCvI=; b=EDOkBaLMTtcPxvMiSLYXKTMxgp8bmFV1R60sPgUYIj8bOJarxd/kh/aLF2J51hot1M RP175v8tJiY0Z5fFydVnulGfkrRDywmOnYFW3wzt/9gUshUddInq/tmRfYP9HwHyca8Y JGcR/x2l8fd3NObE6XzrKkOXlo8P6wehzHN5E3Ofx/MYV2m33duMsWZwzNp1BEWNFXya oIwPvxQNAo9Rmi7XP0+yC6XI6ahpd6rxDxG2FhK3OqB8vhvpOfEbBuy8EjsoAhuHzMoh MzsbaR36iyPmKaKMP1+y8fiq1FU0sDqKy6D0VSYa0I0QoVP6CbfuIc4ckwXW9UxHkyVC Gf4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=raply1yZdwY0rTLYnBKwC+I+8boUM+ePSGAk/7SxCvI=; b=yNYpoPpTt4kfFSqR5YnrXpe4eXqm4FLNhBzNIN1x7S5dKsoYhJy7W50gXimF7Ti+Uv vyMfQ00rspkdnsUH7G/hRQe+DRJ/ThfBmeax0PMgWSDTL3oM4nZ3xg/JV+Z2WyJ1NAhK UteZKz8KfshLbqzsRbFfa6GFcQZR8jwV2MDDMHVrsa3iEhQ9eIql78SFlatbm+dEzzHk +lO/Po3zQ6VnsY/5bxq3isE+JkZjD/cM5sS3tP3XmixYJcwyfGoqWQjpRlF7mOTmUmMt YzF5uawM2ReC2aaKSinkn8zP2tAAfd9du9eJrk7CLxWV1SqcpUYElbkgiRshN2l+QB7k 6Vog== X-Gm-Message-State: ANoB5pnVMXZYYLNWGOFtbFK3xg9ku6+UvOkX6Kd5EkSBdwqPmEhAfiGa 8IzLjq/rhtVIx4ZScOH7Fj0= X-Google-Smtp-Source: AA0mqf6FkG5T2LODhkb2odaQCjgHOfpdRYOLDnxOZwSAWtm+7W2PaT4AG2rEMjRE+UtuHONKTgY5Jw== X-Received: by 2002:a7b:ce8c:0:b0:3cf:8b2d:8cbc with SMTP id q12-20020a7bce8c000000b003cf8b2d8cbcmr10996678wmj.89.1668986225630; Sun, 20 Nov 2022 15:17:05 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id iv7-20020a05600c548700b003cf87623c16sm18614975wmb.4.2022.11.20.15.17.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Nov 2022 15:17:04 -0800 (PST) Content-Language: en-US In-Reply-To: <83v8na5a5e.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248490 Archived-At: On 20.11.2022 09:59, Eli Zaretskii wrote: >> But maybe it will be helpful for you to elaborate: what the workflow >> would look like. Would it be a parallel set of commands, or simply a >> command to... do what? > > I just did that, above: add a command that starts a new "stack". All the > rest is unchanged. What would happen with the current stack, though? Does it get "stashed" at the top of "stack of stacks", switching the current global stack entirely? Until we decide to "pop" to the previous stack, that is (another new command). Or does it apply to the current window? What about the windows split from it? What about older windows we decide to pop-to-buffer to from one of the new windows? You make some good points down below, I just don't see how a new command is going to solve the raised issues entirely. >> In my workflow, a new stack is more or less created implicitly by >> splitting a window, and discarded by deleting one. > > So you always ever have a given buffer displayed in a single window? Not necessarily, no. If it's a big file, I can have two parallel "investigations" going on in two different window on it. Using two different navigation stacks. That's a feature. > Does > it ever happen to you that you need to work on one portion of a file while > looking at its another portion? or work on one file while look at another > file in a sibling window? Sure. > If you ever need to do these, and both windows > show files that belong to the same "editing activity", why would the stack > be local to a window? That would effectively designate a single window as > the only one where M-. and M-, will do what you expect, no? More-or-less-ish. >> The older stacks can get forgotten, but while the locations are fresh in >> mind, this behavior feels logical: it *feels* that I did that chain of >> navigations in one window, and another in the other one. And I can jump >> back and forward in each one in parallel. > > But not if you switch windows? Yup. >> I suppose it doesn't work as well when commands pop new windows a lot, >> but luckily M-. doesn't do that too often. > > In your experience, maybe. In Emacs we have macros like FOO_BAR that call > functions named foo_bar, and then M-. always pops up a new window. Likewise > with macros or data structures that have several different definitions > depending on the window-system backend (X, w32, NS, etc.). Whether M-. pop a new window, or you use project-find-regexp, we usually make sure that after you navigate to a location, it's displayed in the same window the search was made in. Unless the user called something like xref-find-definitions-other-window, naturally. So it's generally possible to stay within the same window most of the time. > The use cases I described don't work well with window-local stacks. So if > an explicit command as I envisioned is deemed an annoyance, perhaps a user > option which will allow one or the other workflow is in order? Sure, it should be optional. I'd like to ensure that the new workflow can be helpful for as many users as possible nevertheless. And you make good points: Emacs often makes you go from a window to a window, reusing older windows as well. So I'm not sure how to solve that better: searching the window hierarchy won't help. So it could be some propagation mechanism working when windows are split or buffers get displayed, which would nevertheless leave a window when the user pressed 'q', for instance. Reverting the window to its previous stack, let's say. And as for separate command, using it explicitly by itself is easy to forget, but it perhaps could be added to some other commands by the user (via before-advice or etc), to mark the beginning of each stack. This is a very rough idea. There's nobody to work on it in the near future, I'm afraid, so adding an optional change in behavior to use window-local storage is probably the best way forward. To get feedback, as Ackerley said.