From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ackerley Tng Newsgroups: gmane.emacs.bugs Subject: bug#59381: Should xref--marker-ring be per-window? Date: Sun, 20 Nov 2022 10:11:30 -0800 Message-ID: References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, 59381@debbugs.gnu.org, Dmitry Gutov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 20 19:12:30 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 1owonr-0008c1-Dy for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Nov 2022 19:12:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owonc-0006dD-Pa; Sun, 20 Nov 2022 13:12:12 -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 1owonT-0006aR-5v for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 13:12:04 -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 1owonS-0002P3-Tp for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 13:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1owonS-00060f-PE for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 13:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ackerley Tng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2022 18:12:02 +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.166896790923073 (code B ref 59381); Sun, 20 Nov 2022 18:12:02 +0000 Original-Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 18:11:49 +0000 Original-Received: from localhost ([127.0.0.1]:44568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owonF-000605-BA for submit@debbugs.gnu.org; Sun, 20 Nov 2022 13:11:49 -0500 Original-Received: from mail-vk1-f182.google.com ([209.85.221.182]:35737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owonD-0005zs-GG for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 13:11:48 -0500 Original-Received: by mail-vk1-f182.google.com with SMTP id r13so4701383vkf.2 for <59381@debbugs.gnu.org>; Sun, 20 Nov 2022 10:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Yp8CodwFg7tUxyL/SmRn7CRRZsXC1G/bc/zMOGcFkoY=; b=fJZA33RHSxFCuXYyxRKjEatbqSxYeH4VMfBAb/Hb5BuZRxQFKPtsJdeZB78knrpT9U x4+ZPaGgEqxbmlJJRIzefT5CEi2oqDOIFpq8cJHPMCcAQJ75t+wJpy6N34p8cJpWdHHv iKmBNlM/vexz54nSLNy1veNlzjonseLUDAiXQnCRyFmuWnTcaBpVtPdh0dadziLWZq22 cgdtAQ+rRan8024woNDDOUsSa5jg9TFFHsMkaR7j271EF9O2hgB7swV5SaE6gh13S0fn WOhWnU/Pmao9qWWsktbPzvUkyIa8FpjTLwZMPRzLbQo/QwZCxapJDURnWpeYVQwswbPO EgCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Yp8CodwFg7tUxyL/SmRn7CRRZsXC1G/bc/zMOGcFkoY=; b=A0EZQFTrYct6IK9WqdV4axT9tVfhoVTtUZ8Ui3P9AEscj9XfqoV6ppscrlN4UfaqiN 7pGS2P0sb7puImytd51ao4KP79Itgmn99Da7wOUC0REpIPeGp9L1NyM8bhVRQJVrfR90 j0c/wbGRrNcKEgoL8p1LTEy3z0VJPYeRaaBH2dEgd6WdZFqW7BPoaRH9NnQLIDcFc2ur L3Yy6IpKZRAY9rb5dXtTfSS7dDaI9LJXnQS/kDgkyg+/FyY8p8gf0x4T8ys+NtdtIatU NOLjZKW+vq4/h77kxRekNLh5LVCFbZtpofZ8kJu2URHt5rrRxejAXSLH4KFEXvguwj7i T5NA== X-Gm-Message-State: ANoB5pkCKFz2nu14W1EM3Yyt9LJlvA2lajzVDo56z0xOyDHBq2v2Guod B/wiWsmMqL/n7QwnUp5E60CEm52ab5HtXWpFxx4= X-Google-Smtp-Source: AA0mqf5p3NL+oxeHtRbH94dVesFg4T37xPsRtg7kDeQ6irj0EDUNu832+apgyR1PvitD8zSQOktkmSwU5YV4cfitIt4= X-Received: by 2002:a1f:43cc:0:b0:3b7:8051:5bc with SMTP id q195-20020a1f43cc000000b003b7805105bcmr2192916vka.31.1668967901810; Sun, 20 Nov 2022 10:11:41 -0800 (PST) In-Reply-To: <83y1s54jmj.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:248448 Archived-At: On Sun, Nov 20, 2022 at 9:32 AM Eli Zaretskii wrote: > > > Date: Sun, 20 Nov 2022 19:00:49 +0200 > > Cc: 59381@debbugs.gnu.org, juri@linkov.net > > From: Dmitry Gutov > > > > On 20.11.2022 09:09, Eli Zaretskii wrote: > > >> From: Ackerley Tng > > >> Date: Sat, 19 Nov 2022 14:01:52 -0800 > > >> Cc: Juri Linkov,59381@debbugs.gnu.org > > >> > > >> What if we copy the whole stackv from the old window whenever a new window is opened? > > > What will happen with that if you switch to another window which displays > > > the same file, or delete the window where the stack is kept? > > > > > > And please note that results of creation and deletion of windows are not > > > always predictable from the user POV. E.g., when you type "C-x 2", do you > > > always know which of the two windows will keep the ID of the original single > > > window? > > > > If the stack is copied, isn't that a non-issue? > > It is, provided that copying is indeed what the user wants. But how can we > know? A new window can be completely unrelated. > > And I'm more worried by window deletion than by creation. I think Eli brought up a good point about splitting windows. Here's the situation that is a little sticky. 1. User builds the stack up to buffer A in window 1 2. User creates a new window, so now we have buffer A in window 1 and buffer A in window 2 3. User builds up the stack further in window 2, AND we have the feature to navigate forwards as eli brought up, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38797#8 4. In window 2, user navigates backwards so that now both window 1 and 2 are showing buffer A 5. User might close window 2, either confused about which stack was in window 1 and window 2, or assuming that window 1 and 2 have the same stacks. Closing window 2 would be bad since the user would lose the go-forward history. However, I feel that if the window position on screen remains consistent, the user would be able to remember where they were navigating, and I think they would close the right window. I feel that for most cases this wouldn't be a problem. I think Eli is right in saying that we will never know when the user wants to fork a navigation stack. My issue with an explicit command is that I would probably forget to initiate a new stack when I need to, and by time I realize it, it would be too late to start/copy the stack. Also, in this new explicit command, the user will have to specify the window to copy the stack from, and the window to copy the stack to, which is quite a lot of steps, which would get in the way of wanting to navigate code. What does everyone think if we do the baseline of just creating a new stack per-window (no copying) and then waiting to see if we get feedback once people start using it? I'm new to development of emacs itself, since in the debbugs link the bug was closed and the feature pushed, are we expecting this feature in a future version of emacs?