From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 19 04:25:23 2022 Received: (at submit) by debbugs.gnu.org; 19 Nov 2022 09:25:23 +0000 Received: from localhost ([127.0.0.1]:39010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owK6F-0003KG-2l for submit@debbugs.gnu.org; Sat, 19 Nov 2022 04:25:23 -0500 Received: from lists.gnu.org ([209.51.188.17]:50034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owGQR-0003TT-Ec for submit@debbugs.gnu.org; Sat, 19 Nov 2022 00:29:59 -0500 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 1owGQR-0001LC-A7 for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2022 00:29:59 -0500 Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owGQP-0006tH-Ub for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2022 00:29:59 -0500 Received: by mail-vk1-xa2d.google.com with SMTP id o24so3373823vkl.9 for ; Fri, 18 Nov 2022 21:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Ng0m0z3o2vNwjMnAu+DxwcAXKGfkCLgVlXQ9xqcVmP4=; b=CNunGPMk48YOnJQzxQI+YuQFC9laMhsIqrP8jOllMQCHjzEiad6d2flkhreune4MNZ sYmBbausERUZPbUVutGJRd8K33CVvzlvqz51HSOKYK+LSEoFKhpJrHjPaBfix/FasbeI jqLYnGCzgG87+TVrmiVUjL+aulMKJ+UVCQzBD6r1Gv7GNA9qSy3x4ig5eesSgOIQtdho iLLrWJXns/aw7K7BxxztiZSad9HI+8LF8SoSy2SNBAWk66pTVhdiD+FXIxiUVzCWx+DM 9CUlSkfEK/+4cvetZLPUwVCCDk/wCBtmj/9CDU4rGOVZzf5YCpW1/6HFJ6gWvo2fOwqE WbaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Ng0m0z3o2vNwjMnAu+DxwcAXKGfkCLgVlXQ9xqcVmP4=; b=GAlpKqH17MWCx5Kn6ICjW4Df/PfrQGWauo6XcTsUg1Bntm8SwJgPOfNv9cyDmuY4R0 C1RqK/AbPQi2x/xos0J/EOh+RytUtYkgxVpi2YlLUxaAX+u4cCt4fW+sw/87UM7qqkQJ DW8xIIpRUCBe1Ah4aMv8wR6ooyQdwDNYT53+LQTzbs92WnQ1yFbegvymhDMERSvCYj2j PLi0LKwAljL4d4t8xxNF2TKaH4MtpsP9Fj4XsCuzUSaEtwj9NrRsHao+cIPFhkwilsVV SFkr9+69vUs7L/FHcmUwTYjtmy8jwcnaYiFweUcx6l+gCROlkO8sl4OkfH0SlgY/3Oas qQHg== X-Gm-Message-State: ANoB5pnkk9CGp+fI0n5+WC7I1bmENbwB67aeiP3oroXhMND3nFcE8blS qzCjcGNgONNLH8W5RinvISKkkArESmQ6MNCpptNUYiRpcY4= X-Google-Smtp-Source: AA0mqf5I3o1TEnA+PDjdySV0DrMNLTwpUeag6lQ2KBjyOZwQpdOhNDkMryeXabxzTLDdunjy8arhrq4CauEqbHMhGa4= X-Received: by 2002:a05:6122:12a7:b0:3b8:969f:97ba with SMTP id j7-20020a05612212a700b003b8969f97bamr330579vkp.0.1668835796166; Fri, 18 Nov 2022 21:29:56 -0800 (PST) MIME-Version: 1.0 From: Ackerley Tng Date: Fri, 18 Nov 2022 21:29:45 -0800 Message-ID: Subject: Should xref--marker-ring be per-window? To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::a2d; envelope-from=ackerleytng@gmail.com; helo=mail-vk1-xa2d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 19 Nov 2022 04:25:13 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, While using xref (xref-find-definitions and xref-find-references, etc) in separate windows, I hit M-, to pop the marker stack expecting that each window should have a separate stack. However, it seems that the entire emacs instance shares a single xref--marker ring. Could we have separate xref--marker-rings per window, or some configuration option to enable that? I have some patches that I could submit, if that helps! Thanks, Ackerley From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 19 05:23:44 2022 Received: (at control) by debbugs.gnu.org; 19 Nov 2022 10:23:44 +0000 Received: from localhost ([127.0.0.1]:39083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owL0h-0004nX-RR for submit@debbugs.gnu.org; Sat, 19 Nov 2022 05:23:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owL0g-0004nL-8g for control@debbugs.gnu.org; Sat, 19 Nov 2022 05:23:42 -0500 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 1owL0b-0005cz-2v for control@debbugs.gnu.org; Sat, 19 Nov 2022 05:23:37 -0500 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=Fy7P0CWAyRXWQWQmr9mx8ENX0jjOd+yWX33CLAQp618=; b=KNuctiOE6UOU d5kqvXIk2BeZLyfjWufoBV9mc+WahvUMX/6RUKXJWmtxGEMVEXksfwv0csw7j4dyyMNX21A2n+7Rz FCQjEIRtwAZGROhK8HbLVNEkGm0PcZgtxOKj0FAZIvHNTSRWiLl+TfgDdifT3+eMv5SqZWakh39MV 5ML7awLW94O9rUBRP92hbr3lXcnWsokLT5rmTQqGR4aFDun2pC3flSefymKKRFTVCv1Sjl5yzMAcs KXWO9f+dXkO4qRoWKo87uIHfcyG/f4osjktFGdScZeiFXPjnzdJkvpNsQHdy2h8sMJoJ+Tv5Izod9 C29FUd7GT3jmYZBLuFiTvw==; 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 1owL0a-0004kJ-Ht for control@debbugs.gnu.org; Sat, 19 Nov 2022 05:23:36 -0500 Date: Sat, 19 Nov 2022 12:23:43 +0200 Message-Id: <83tu2v8cpc.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-Reply-To: (message from Ackerley Tng on Fri, 18 Nov 2022 21:29:45 -0800) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) severity 59381 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 19 14:16:09 2022 Received: (at 59381) by debbugs.gnu.org; 19 Nov 2022 19:16:10 +0000 Received: from localhost ([127.0.0.1]:41442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owTJx-0006Pc-Iw for submit@debbugs.gnu.org; Sat, 19 Nov 2022 14:16:09 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:41305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owTJa-0006LD-8x for 59381@debbugs.gnu.org; Sat, 19 Nov 2022 14:15:46 -0500 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 10DC3C0005; Sat, 19 Nov 2022 19:15:36 +0000 (UTC) From: Juri Linkov To: Ackerley Tng Subject: Re: bug#59381: Should xref--marker-ring be per-window? In-Reply-To: (Ackerley Tng's message of "Fri, 18 Nov 2022 21:29:45 -0800") Organization: LINKOV.NET References: Date: Sat, 19 Nov 2022 20:53:46 +0200 Message-ID: <86leo6ai85.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 59381 Cc: 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > While using xref (xref-find-definitions and xref-find-references, etc) > in separate windows, I hit M-, to pop the marker stack expecting that > each window should have a separate stack. > > However, it seems that the entire emacs instance shares a single > xref--marker ring. > > Could we have separate xref--marker-rings per window, or some > configuration option to enable that? Ideally, making an existing variable window-local should be as easy as making it buffer-local, e.g.: (make-variable-buffer-local 'xref--history) -> (make-variable-window-local 'xref--history) But we are not here so far. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 19 14:53:30 2022 Received: (at 59381) by debbugs.gnu.org; 19 Nov 2022 19:53:30 +0000 Received: from localhost ([127.0.0.1]:41489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owTu6-0007KP-A0 for submit@debbugs.gnu.org; Sat, 19 Nov 2022 14:53:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owTu2-0007KA-KV for 59381@debbugs.gnu.org; Sat, 19 Nov 2022 14:53:29 -0500 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 1owTtw-0007XR-TL; Sat, 19 Nov 2022 14:53:20 -0500 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=ysWVTuCdsHDAspWzM47Xcuo8DnAKPW0hhvyNvuxPQwg=; b=kua8nipWnQg+ 8TWKAOgX4J13DY+eGm/HtAfuLGFwgG8F8d3eBxXIK8pNvlWigySvkMStpmKGs/YQx6H/KyoS4d8Tc hXLY8DymIeVBAoNVfaZAGSztkyJ+EbCAbyxwd4uHHAnl4MO/pVamDTREv5wkhMnMU4J94qRPskkgR x8VHOduMIvZ73nS0p3j5nj1vBlByrDfr4AB/BfR3eFfJcGDysRGTgkJxyB3BlwCo7WcLv7YJWHf1v 6FH2B+JwieZIV4H32j4vHnDdduHH8Z/FSxx9ex/R2vXxeUz18SbaSyj9WQwDty0d4Mg4GMixxxJXE 4u8Z1NiMkShtduONTlSdhw==; 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 1owTtw-0008Q9-3m; Sat, 19 Nov 2022 14:53:20 -0500 Date: Sat, 19 Nov 2022 21:53:26 +0200 Message-Id: <83leo67mbt.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86leo6ai85.fsf@mail.linkov.net> (message from Juri Linkov on Sat, 19 Nov 2022 20:53:46 +0200) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59381@debbugs.gnu.org > From: Juri Linkov > Date: Sat, 19 Nov 2022 20:53:46 +0200 > > > While using xref (xref-find-definitions and xref-find-references, etc) > > in separate windows, I hit M-, to pop the marker stack expecting that > > each window should have a separate stack. > > > > However, it seems that the entire emacs instance shares a single > > xref--marker ring. > > > > Could we have separate xref--marker-rings per window, or some > > configuration option to enable that? > > Ideally, making an existing variable window-local should be as easy > as making it buffer-local, e.g.: > > (make-variable-buffer-local 'xref--history) > -> > (make-variable-window-local 'xref--history) > > But we are not here so far. I don't think it's that simple. Windows are much more ephemeral than buffers; for example, "C-x 2" followed by "C-x 1" or "C-x 0" deletes one of the windows. What do we want to happen with the "window-local" xref stack in that case? My guess is that the OP wanted to have control on when M-. pushes locations to the last used stack or begin a new stack. Because only the user knows when M-. begins a new series of searches. So I think it is better to offer a separate command for exercising just such control. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 19 21:52:52 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 02:52:52 +0000 Received: from localhost ([127.0.0.1]:41930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owaRv-0002ly-NM for submit@debbugs.gnu.org; Sat, 19 Nov 2022 21:52:52 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:44752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owaRr-0002lh-PH for 59381@debbugs.gnu.org; Sat, 19 Nov 2022 21:52:50 -0500 Received: by mail-wr1-f43.google.com with SMTP id v1so15032088wrt.11 for <59381@debbugs.gnu.org>; Sat, 19 Nov 2022 18:52:47 -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=bMzDjYxbfW1gPrUoNvWtOWpbCFP8VZBYzEt/AXvf5fo=; b=pUwfcT8skXkcHkoizeyGZ6QoVowcmDa/96bAxpK8+b/IDnrStB/GlE5WGjNc42PHd+ v3ZOeFerFmoRfqpDbC5w4SCBa2wyKyefGR2lXbw2XvZNlGsbDAte/irJnt5+EFWPBx2d N3AwHxyQFs0sTkaOv9/Bc97PYh6jCDhqCRaHO9K4MkTmsNnB9dgptu2baAT7v7JG+6+q V5nqq4Bf6Eiz5aR+grBzlST2VVaSsupVJr89LiDb9yCJSp0r959/YDl7Xf+mEnjv4c4M S+71R9pwoe3QCSn3hXs3SLYma/MSfXN5eAtG3Sw6AmCcp7RPFHTEXT6DA6C6zOvBqACT YIvw== 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=bMzDjYxbfW1gPrUoNvWtOWpbCFP8VZBYzEt/AXvf5fo=; b=jvBgdd8FKFU8VBAZ0iL5qyClrJs7arKNv5s+XemR20doQH03oqAmx5lPH4tn9wPB7V jhjP7AdawIFADoGttDy5e6KW+RMmKfQeYyaLAiLIQo0T3iKt5vqD7YQJYEWW91ZpYdH0 MAhkfzrU6bGxvugwQbzRa7wnJ+APusQfLT3e+E1fQ/00ZliLHAsebpwW/9R7y0TYKnQp MjHavOeukjnhzmLVC17DYULlWqi2DZnpfJMpD+CKNn3pBLt9CuSCVRjPticKgAfWE1sV LbDrOwb625hoc9SSLo3M9cuIdRbldmR3VHhPTdkbQJ3qPN9aNHkTXTbaQ4IJww5ATA7d kMew== X-Gm-Message-State: ANoB5pnTQqKxXP7iLNDtNWLKUSZcebztAe7qQPVch70aRkq0QPEi74QD yzeKOHQGHhEjYSHk40z5TqI= X-Google-Smtp-Source: AA0mqf6PGdOMwGOJQJBmgmbObYLYmCf5jptUb6x2vYtrO0HL034YEK3ghry34h8/U0+pAfYU55sdYA== X-Received: by 2002:adf:f0ca:0:b0:241:d05a:73e8 with SMTP id x10-20020adff0ca000000b00241d05a73e8mr944566wro.592.1668912761381; Sat, 19 Nov 2022 18:52:41 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j39-20020a05600c1c2700b003cf57329221sm15095907wms.14.2022.11.19.18.52.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Nov 2022 18:52:40 -0800 (PST) Message-ID: Date: Sun, 20 Nov 2022 04:52:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Eli Zaretskii , Juri Linkov References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83leo67mbt.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 19.11.2022 21:53, Eli Zaretskii wrote: >> Ideally, making an existing variable window-local should be as easy >> as making it buffer-local, e.g.: >> >> (make-variable-buffer-local 'xref--history) >> -> >> (make-variable-window-local 'xref--history) >> >> But we are not here so far. > I don't think it's that simple. Windows are much more ephemeral than buffers; > for example, "C-x 2" followed by "C-x 1" or "C-x 0" deletes one of the windows. > What do we want to happen with the "window-local" xref stack in that case? Poof. Not sure what else we could do. > My guess is that the OP wanted to have control on when M-. pushes locations to > the last used stack or begin a new stack. Because only the user knows when > M-. begins a new series of searches. So I think it is better to offer a > separate command for exercising just such control. As previously mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38797#8, I personally find it perfectly usable to always use window-local stacks. 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? In my workflow, a new stack is more or less created implicitly by splitting a window, and discarded by deleting one. 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. I suppose it doesn't work as well when commands pop new windows a lot, but luckily M-. doesn't do that too often. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 01:37:30 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 06:37:30 +0000 Received: from localhost ([127.0.0.1]:42190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owdxI-0008W7-4c for submit@debbugs.gnu.org; Sun, 20 Nov 2022 01:37:30 -0500 Received: from mail-vs1-f45.google.com ([209.85.217.45]:39792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owVub-000474-9B for 59381@debbugs.gnu.org; Sat, 19 Nov 2022 17:02:12 -0500 Received: by mail-vs1-f45.google.com with SMTP id m4so7994908vsc.6 for <59381@debbugs.gnu.org>; Sat, 19 Nov 2022 14:02:09 -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=j1/btV4T7P01yc0mNx3P47yTH+ZIHz5IxIMbEce6cCc=; b=Aa63yhMAcEOUil+9nmyfaj103M3s6p5G1NbOI2zAGHOiC9hw3G0s4WKARXIIR5hCrv XYfAxW36Wb1w6PxC7IPCyzR/VpRJHz2WHWbuBTgcea4AvzuCU4t6OrYHn4gUi406orSM x1gdWuwRbW5/TVV1p5XNXaumbbBT/oCwJ0F8kQiBGYSC3AZZv97SubV6FoIzegH6bEYb yWx72m6ERCP3wMsu0J8V9VxM/RdBIc9a92wRa6WRP3VWEixJPbHLbAEh0i1pyDINWM9N A9Ge24OnDDwhfhejfC5NadbHqkFr8cUDI7DW/AUWFZlIWmL7MfQfsbsSF1/N48fUOFL9 63NQ== 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=j1/btV4T7P01yc0mNx3P47yTH+ZIHz5IxIMbEce6cCc=; b=yI/clNYkB+hY9C1iS6jhMKtyzNieJESDu5qOx9wRkVhoX6MnTCnj1waaFq1OnSEX7s RaomA5AqO16eFW8GaMMVTYkA0ayaJGwiyGRdyhIH0r60J/2pyrBw7a6DeaGPFGRM9pO5 YMuz9iFPzl3PA/kksspguy6q6piVd/ORu9VYHcIirl9WF7io3WKlC249S0oOitooCJ2g 1w7IO8/usXSWbWuucC4OYPajb4XKJ6ozXvxQf6gB2hYMmsEiLS/TAeYzzseuYIMu+GuJ 7KPX9iujTdutgPXGfRROGgeTad19FYRWa2dGM4lAJltbSECc3vVVJQfocflgB6Ho6hhl ZMrg== X-Gm-Message-State: ANoB5pnd4zDwZRGYwCFcTwFhhOB1S4QF8y8Ti1q5iDP+D/mFIcF4gUtJ 5bXeLR5CHAHO1AAob8iPZ187L/6janjcxK+2s/U= X-Google-Smtp-Source: AA0mqf6i9XT/FD3QHjvcDkeeayJpd1id9SxYrti4VMY3mSPOR1BcGkdjx4142RtM1hhMBz95hT7h21Gxv4si3uTs2kU= X-Received: by 2002:a67:fd09:0:b0:3af:ce07:c3d4 with SMTP id f9-20020a67fd09000000b003afce07c3d4mr7064469vsr.25.1668895323506; Sat, 19 Nov 2022 14:02:03 -0800 (PST) MIME-Version: 1.0 References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> In-Reply-To: <83leo67mbt.fsf@gnu.org> From: Ackerley Tng Date: Sat, 19 Nov 2022 14:01:52 -0800 Message-ID: Subject: Re: bug#59381: Should xref--marker-ring be per-window? To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000eccbf305edd9f80a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59381 X-Mailman-Approved-At: Sun, 20 Nov 2022 01:37:26 -0500 Cc: 59381@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000eccbf305edd9f80a Content-Type: text/plain; charset="UTF-8" What if we copy the whole stackv from the old window whenever a new window is opened? On Sat, Nov 19, 2022, 11:53 AM Eli Zaretskii wrote: > > Cc: 59381@debbugs.gnu.org > > From: Juri Linkov > > Date: Sat, 19 Nov 2022 20:53:46 +0200 > > > > > While using xref (xref-find-definitions and xref-find-references, etc) > > > in separate windows, I hit M-, to pop the marker stack expecting that > > > each window should have a separate stack. > > > > > > However, it seems that the entire emacs instance shares a single > > > xref--marker ring. > > > > > > Could we have separate xref--marker-rings per window, or some > > > configuration option to enable that? > > > > Ideally, making an existing variable window-local should be as easy > > as making it buffer-local, e.g.: > > > > (make-variable-buffer-local 'xref--history) > > -> > > (make-variable-window-local 'xref--history) > > > > But we are not here so far. > > I don't think it's that simple. Windows are much more ephemeral than > buffers; > for example, "C-x 2" followed by "C-x 1" or "C-x 0" deletes one of the > windows. > What do we want to happen with the "window-local" xref stack in that case? > > My guess is that the OP wanted to have control on when M-. pushes > locations to > the last used stack or begin a new stack. Because only the user knows when > M-. begins a new series of searches. So I think it is better to offer a > separate command for exercising just such control. > --000000000000eccbf305edd9f80a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What if we copy the whole stackv from the old window= whenever a new window is opened?

On Sat, Nov 19, 2022, 11:53 AM Eli Zaretskii= <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> Cc: 59381@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Sat, 19 Nov 2022 20:53:46 +0200
>
> > While using xref (xref-find-definitions and xref-find-references,= etc)
> > in separate windows, I hit M-, to pop the marker stack expecting = that
> > each window should have a separate stack.
> >
> > However, it seems that the entire emacs instance shares a single<= br> > > xref--marker ring.
> >
> > Could we have separate xref--marker-rings per window, or some
> > configuration option to enable that?
>
> Ideally, making an existing variable window-local should be as easy > as making it buffer-local, e.g.:
>
>=C2=A0 =C2=A0(make-variable-buffer-local 'xref--history)
>=C2=A0 =C2=A0->
>=C2=A0 =C2=A0(make-variable-window-local 'xref--history)
>
> But we are not here so far.

I don't think it's that simple.=C2=A0 Windows are much more ephemer= al than buffers;
for example, "C-x 2" followed by "C-x 1" or "C-x 0= " deletes one of the windows.
What do we want to happen with the "window-local" xref stack in t= hat case?

My guess is that the OP wanted to have control on when M-. pushes locations= to
the last used stack or begin a new stack.=C2=A0 Because only the user knows= when
M-. begins a new series of searches.=C2=A0 So I think it is better to offer= a
separate command for exercising just such control.
--000000000000eccbf305edd9f80a-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 02:09:26 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 07:09:26 +0000 Received: from localhost ([127.0.0.1]:42219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oweSD-00015S-UU for submit@debbugs.gnu.org; Sun, 20 Nov 2022 02:09:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oweSA-00015D-6i for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 02:09:24 -0500 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 1oweS4-0004Ot-JK; Sun, 20 Nov 2022 02:09:16 -0500 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=AMElnfqm1Drd6ZrDiiHTXdMMgePOeDG3S/5026KXUMI=; b=QHZkc1YyYZ8H iKdBpwykGbn1nMOPpNEJ4bMEo0prl5RhfNVal+8ugusp6pHPTcHhjvTlmqgA/DoPbF5XGfRUOr0DA zZvW+5ivOCxNbY31x0cLo+qvlLCkGkYDjtinNjDvWBgLMbL1yoAqpwD6CSvwErPl6UWeAJ+Pu6RKe 8Hxa9xXKXD9BxkpuE8CVj0jq4d7moY6UBVlKDf04G/sZ4pnHFFtvP0aH13ExS+gzYkPVTJtsadQur 7zWGYsgnW/SraYn8OG1tWnIPUWHSoZld1Tb6NmWEb+zvViPz5X00fU3PiBXMediHE8992s0RURJ4p vblfeMmnAvBjF+6zQqFMAw==; 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 1oweS4-0006aq-2e; Sun, 20 Nov 2022 02:09:16 -0500 Date: Sun, 20 Nov 2022 09:09:24 +0200 Message-Id: <838rk66r17.fsf@gnu.org> From: Eli Zaretskii To: Ackerley Tng In-Reply-To: (message from Ackerley Tng on Sat, 19 Nov 2022 14:01:52 -0800) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: 59381@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 02:59:25 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 07:59:25 +0000 Received: from localhost ([127.0.0.1]:42270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owfEa-0002IK-LW for submit@debbugs.gnu.org; Sun, 20 Nov 2022 02:59:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owfEY-0002I6-FJ for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 02:59:23 -0500 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 1owfES-0006Nn-LE; Sun, 20 Nov 2022 02:59:16 -0500 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=t9fiMaeyWlhQN5BF7BX9kcdd6wbZEjv7Z+bBW1GL6q8=; b=lbaytpY6rtT4 CZsP7q7Ccff3TbdR71zoF73hnR75f1SX6WMJfMwjUMOv+TgdoR7otLVNR2HntMvsO1JL4N7Vt6AQy xRvsfaQXj8n6xAPES2YBc23uh41CjCqMhAaw9O3LYNzN3NwJQOkeHw/5SQWqHkDHSZ48xAgfid5rE Z01m5aHdHEXnrQ8jlZqlDejk8J45vfmCYaIMtx/bLFsfrKbZWzCh90/fDHlZMrJk4U7zm+fkNLv8h bdWNuWpI2mf75/VwTT1lvhsmeq1qOwLF6qn79rkXKCVCpv1xJZ3RcvGaiVe0QcqhAWrIhOQiFPnHr 0LQ+ZL5oTAD3uscGrCzuaA==; 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 1owfES-0006Jn-1b; Sun, 20 Nov 2022 02:59:16 -0500 Date: Sun, 20 Nov 2022 09:59:25 +0200 Message-Id: <83v8na5a5e.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 20 Nov 2022 04:52:38 +0200) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 20 Nov 2022 04:52:38 +0200 > Cc: ackerleytng@gmail.com, 59381@debbugs.gnu.org > From: Dmitry Gutov > > > My guess is that the OP wanted to have control on when M-. pushes locations to > > the last used stack or begin a new stack. Because only the user knows when > > M-. begins a new series of searches. So I think it is better to offer a > > separate command for exercising just such control. > > As previously mentioned in > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38797#8, I personally find > it perfectly usable to always use window-local stacks. > > 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. > 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? 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? 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? > 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? > 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.). 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 12:01:01 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 17:01:01 +0000 Received: from localhost ([127.0.0.1]:44408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owngi-0001pa-SG for submit@debbugs.gnu.org; Sun, 20 Nov 2022 12:01:01 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:43679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owngf-0001oz-LS for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 12:00:59 -0500 Received: by mail-wr1-f45.google.com with SMTP id g12so16621857wrs.10 for <59381@debbugs.gnu.org>; Sun, 20 Nov 2022 09:00:57 -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=DkvEDYHnXIPMeaas1u0Yz2U3TxR/eoFNhWoOp/dzqhs=; b=labkl5z6GamPzQjeu3lpcFkNOOWMvK2WExRAnLONfdjuwrjxyri98/9hAe1x2NhFnS QHhtjQVJcGLPUy+hNWeHWqG9LBG/p3qeYLlJQ/aHW97ym36F5K9MPIGadCezy8q4Jaau DSC1I+CJpomv99ass3RxjoAFC1m0qc3Ns3dlLGw2dBVSyMGOYgJd1Ls0uxTG5UcCv3pf GTZQ9QUm6TY8bPyYjCl7pmELWeEdfAUHwwIPU/+gbzZpgi6OSSSdegm63ImXkhYWNLxd d9gtlmWhplLpV1PLHFn8oY8HA01qs42waYkmk/shHo2e5fk4dO8fBE0dokxIrJK2aqEj c6lg== 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=DkvEDYHnXIPMeaas1u0Yz2U3TxR/eoFNhWoOp/dzqhs=; b=ssueQimoWzd0W3Bf+Cd81AET8Gxum6MTKJks5zrJTm0LdmpqW4ON1oqxg8MXWtxaM3 pnWWR7/3VwnyThPy+FnqFzcOT9ZbHW4oj2MnGlZBx4hPses2VY5ejbN4APYElSJBEITG RUmaE80vI+E5afoXlO4XKKIlVZnfS6nrFVxJrJjo0nZzjpnHivTq3AnA9ZgNbbFy1cvZ Hv1lv2u9SU99fCZkrqnFx6H26zHCkn3ggeMtghxpVFU21W1z9QY+dXSktdiBVHKQst/a fcIgKFI+qBordoZuJ2u6rM1ot7Z06DFZajegc4Y+FfTai645hlMn34jLqRTwfZbiUn9D QRpw== X-Gm-Message-State: ANoB5plFh8SUcckIUAflxcTtdZyL4zstW678Er3vZVGN01MAfB5GDYvJ kFV7MENwkKS3uvx2OIYVP+o= X-Google-Smtp-Source: AA0mqf49iMr8m5yNmS0g6PHG1fCPQVoJ1JrEDbLQPXTNUxSOXT2VHted74JArKVulEEo+VP5nxB88w== X-Received: by 2002:a05:6000:60a:b0:241:d4ae:8e3f with SMTP id bn10-20020a056000060a00b00241d4ae8e3fmr1264895wrb.437.1668963651558; Sun, 20 Nov 2022 09:00:51 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q3-20020adfcd83000000b0022eafed36ebsm9182767wrj.73.2022.11.20.09.00.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Nov 2022 09:00:51 -0800 (PST) Message-ID: Date: Sun, 20 Nov 2022 19:00:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Eli Zaretskii , Ackerley Tng References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <838rk66r17.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) 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? Both windows get the same history, and then their identities will be tired to the positions on the screen, that's how the user will recognize them. And FWIW, in my personal config the stack isn't even copied. Somehow that works out fine, with one small (but potentially significant) caveat that in my config 'C-x 2' and 'C-x 3' always select the new window. Making it obvious which of the windows in new, and thus isn't expected to have existing history. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 12:32:28 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 17:32:28 +0000 Received: from localhost ([127.0.0.1]:44487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoBA-0002kG-BH for submit@debbugs.gnu.org; Sun, 20 Nov 2022 12:32:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoB7-0002jy-SR for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 12:32:26 -0500 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 1owoB2-0000ii-6m; Sun, 20 Nov 2022 12:32:20 -0500 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=7hmYGMfw/iLDhjc1e250dUVdSNMJupppwbOFx2bnVpw=; b=Uui5LPIsjPtN PKGFo1sFRqz6ObqbvXyjZ7vWmqMvezQGcVMJvqyXWjEgRjQ/vYK8fmfAKb+X1VWWdrFyauJo8xTgd Cikn+NVBduQNJ8ceuR5vCzi8EKS4XoOl+7mK2AQlorTmry/rybqdOK9CRMkrwBYz0gu2Jiy1NYZMn izQzqm/dpMHNMcMa9eD09wGITtX+6WMw+AQdXiMES7xg1APJavQY1Z5Dr/6AlkmZurCj0tSiKA9zq bHEjclQirbWo3U+omZo7tdjyPpbKyubGkzFtD33UfhqU0WHZlSBBHB9FLAVk4MQldqk52I1lp4iM/ PGh5R8dQmHW9SGY3wvt+sw==; 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 1owoAt-0001ih-SS; Sun, 20 Nov 2022 12:32:19 -0500 Date: Sun, 20 Nov 2022 19:32:20 +0200 Message-Id: <83y1s54jmj.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 20 Nov 2022 19:00:49 +0200) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. > And FWIW, in my personal config the stack isn't even copied. Somehow > that works out fine, with one small (but potentially significant) caveat > that in my config 'C-x 2' and 'C-x 3' always select the new window. > Making it obvious which of the windows in new, and thus isn't expected > to have existing history. I don't see how this could work reliably enough. Maybe I'm missing something. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 13:11:49 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 18:11:49 +0000 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 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 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) MIME-Version: 1.0 References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> In-Reply-To: <83y1s54jmj.fsf@gnu.org> From: Ackerley Tng Date: Sun, 20 Nov 2022 10:11:30 -0800 Message-ID: Subject: Re: bug#59381: Should xref--marker-ring be per-window? To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 13:22:25 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 18:22:25 +0000 Received: from localhost ([127.0.0.1]:44597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoxV-0006HL-1r for submit@debbugs.gnu.org; Sun, 20 Nov 2022 13:22:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoxT-0006H7-1x for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 13:22:23 -0500 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 1owoxN-0004tt-4p; Sun, 20 Nov 2022 13:22:17 -0500 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=gRsPdWzkZ5kMox6H2V5LxZSVs8+WAX9pJiUuKVY0fHE=; b=nEEYJafDvcF3 l+HqFsqTXamQPUmZyg1DbUqNnmxdx5vJe45oDWVPSyKp9oIdUvYuvTwwMni3Q1Mi7RSpCe0KNc2wz zlTo4I9CP6nB0AfiU/PQn3WwNtFZTIVfpG83nenaDiQONj8oj0HjxG2Sesrsbk9/Tk+L1RfBkAEjs +EUovVUDsXOl2hnsETyREiqw3sSmMUd4ww1zkXM1xsliEaNyPPwVzRjY9sdcCY8+r0ZTrOVNMku+8 TSyvDwabDNFjiIYF1jgS24ZtGFOT6H2z+CiCDZrKj9AhM7epUeIfsEVoNIaeGN1C4rPuUrNr+PdRn CBGG8rdqa/ZidS5mSqwD6g==; 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 1owoxM-0002Tb-L2; Sun, 20 Nov 2022 13:22:16 -0500 Date: Sun, 20 Nov 2022 20:22:26 +0200 Message-Id: <83r0xx4hb1.fsf@gnu.org> From: Eli Zaretskii To: Ackerley Tng In-Reply-To: (message from Ackerley Tng on Sun, 20 Nov 2022 10:11:30 -0800) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ackerley Tng > Date: Sun, 20 Nov 2022 10:11:30 -0800 > Cc: Dmitry Gutov , 59381@debbugs.gnu.org, juri@linkov.net > > 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? If this is optional and can be disabled, I don't think I mind. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 18:01:18 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 23:01:18 +0000 Received: from localhost ([127.0.0.1]:44872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owtJO-000797-G5 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 18:01:18 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:34563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owtJJ-00078m-KT for 59381@debbugs.gnu.org; Sun, 20 Nov 2022 18:01:17 -0500 Received: by mail-wr1-f45.google.com with SMTP id s5so232566wru.1 for <59381@debbugs.gnu.org>; Sun, 20 Nov 2022 15:01:13 -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=411LHZX9Vgc9o1K8/oAgj6MecVchOP2LGdwxkdtfgcs=; b=DXJu6j2owu3l4VpT/hskIjN4Si5YoJiAPkdEEPTbyKrmybGSUIabZN/tyOjWKXoYAc I55o60fEmf26RTKzpkQh9orbWY43XzSfmdmjtsqPYiQIftyZGYJ1y5BcQSx1UIIQb1y4 XqjXbv31DEN2nUR4ri0eYbcDEDT0n7a9DvjpPYkHcLp0jwbFCi5QUpgZntOuEURQUM2g X9ymdg7G941uLcbTA2rGka4Zm8KX/mE57MD1c1SexUpREn5Jn+sFV5++4nXkntk5q+PU dmkLN+JqIcc33dwkwuXts5UZhixiYJ9DzflkqCIRgT4v/iRervzwGhTprpxGTft2xFVJ 7mGA== 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=411LHZX9Vgc9o1K8/oAgj6MecVchOP2LGdwxkdtfgcs=; b=nexRyyK1dDQNSG8ENY3i6/V7XlQNsVXoZZs97VxwCNZrOi20m7kTKoi52eyEx/V7BW eZokmWB6K6rNPCEderRt8ozQ4SM1SkrLR8Bh+3n1AIRvHV7VVb0BahcsKsvar1Ce95j7 T7y+ghvvqfGP8EXMnxtXQWYousOF/k1WAuxAgz33pVViefoU4CB0NH/zLzzRsG14qgh/ iCfEyF+5ShWQ2Djj7+Bz2Cktztp93HYe55iu1mcFvbtXi0c8BbRvrEm2ChQs+9K6FvMr 5v9CAGmkq47txJz/C/XIOBgPFOKZcvWkFqjRhG6PqXP8C9iFvgOhq96JjUrvhnZZmpGu Eo/Q== X-Gm-Message-State: ANoB5pnmTUvkNPtyhvxqS0Nfnp3KNBG7acZyNvl4zlOziI4SSVlEh/WG yARQUGdpzQHTaqhXPM7GENw= X-Google-Smtp-Source: AA0mqf61zQ7jpjP8g8mpwkEtCAvy+oZH5wTMGomeGq8CUPC+ZG/wEZbXTrAQpIabD2fgttg0g4MZdg== X-Received: by 2002:adf:cd86:0:b0:236:8a6d:72a1 with SMTP id q6-20020adfcd86000000b002368a6d72a1mr9154459wrj.682.1668985267998; Sun, 20 Nov 2022 15:01:07 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g17-20020a05600c4ed100b003c701c12a17sm18395468wmq.12.2022.11.20.15.01.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Nov 2022 15:01:07 -0800 (PST) Message-ID: Date: Mon, 21 Nov 2022 01:01:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Eli Zaretskii , Ackerley Tng References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> <83r0xx4hb1.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83r0xx4hb1.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 20.11.2022 20:22, Eli Zaretskii wrote: >> From: Ackerley Tng >> Date: Sun, 20 Nov 2022 10:11:30 -0800 >> Cc: Dmitry Gutov,59381@debbugs.gnu.org,juri@linkov.net >> >> 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? > If this is optional and can be disabled, I don't think I mind. Definitely optional, we should provide different "storages" for this. Global (the current behavior), per-window, per-frame, maybe others. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 18:17:18 2022 Received: (at 59381) by debbugs.gnu.org; 20 Nov 2022 23:17:18 +0000 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 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 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) 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) Message-ID: Date: Mon, 21 Nov 2022 01:17:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Eli Zaretskii References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83v8na5a5e.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 02:58:21 2022 Received: (at 59381) by debbugs.gnu.org; 21 Nov 2022 07:58:21 +0000 Received: from localhost ([127.0.0.1]:45245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox1h7-00060T-Fu for submit@debbugs.gnu.org; Mon, 21 Nov 2022 02:58:21 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:53393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox1h1-000603-R9 for 59381@debbugs.gnu.org; Mon, 21 Nov 2022 02:58:19 -0500 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id DB68460007; Mon, 21 Nov 2022 07:58:06 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#59381: Should xref--marker-ring be per-window? In-Reply-To: (Dmitry Gutov's message of "Mon, 21 Nov 2022 01:01:06 +0200") Organization: LINKOV.NET References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> <83r0xx4hb1.fsf@gnu.org> Date: Mon, 21 Nov 2022 09:42:08 +0200 Message-ID: <864jus4y3b.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 59381 Cc: Eli Zaretskii , Ackerley Tng , 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> 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? >> If this is optional and can be disabled, I don't think I mind. > > Definitely optional, we should provide different "storages" for > this. Global (the current behavior), per-window, per-frame, maybe others. Also per-project (maybe even by default). PS: this whole subject of different xref stacks reminds me trying to make sense of the different next-error stacks ;-) From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 08:14:37 2022 Received: (at 59381) by debbugs.gnu.org; 21 Nov 2022 13:14:38 +0000 Received: from localhost ([127.0.0.1]:45747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox6dB-0006Qh-F2 for submit@debbugs.gnu.org; Mon, 21 Nov 2022 08:14:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox6d8-0006QS-Nm for 59381@debbugs.gnu.org; Mon, 21 Nov 2022 08:14:36 -0500 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 1ox6d2-0001o5-Ml; Mon, 21 Nov 2022 08:14:28 -0500 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=QAD1oFjpfzSZK0XAeiX1E3fWpBtMavzTmbXu+G7B/vM=; b=EkjhS1ycuICb m4VqcY8ZvncliHORX0deulgMfgrDAh1m7fyer808D+EPLnIgk/6CL7lv983VkiH9eg7sHkNVSXxCi TC0s8y/RUSqyJnLOj3BLPHDgW5oVoxSZaygf5OQQGL5RHTE/w3Fqs/7mwj8e8ZQxYtTDxOg4e5vNK 9Be0qDv18QaGKFhv7qc1GuUbUF8p9bkATETb+Oun7GR4VU0Ja2FjgL9vDNxo0dOO2ewy05KrcSLJy jOADQIQVjnSK2ebxWklOl+2RtqJxiHgWgJaggSA6p/c+DVk6YbCymF324RgJLxVHuVA78H30os26x FffiuAhPzc1nJuKOe2e56g==; 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 1ox6d1-0002dn-Ve; Mon, 21 Nov 2022 08:14:28 -0500 Date: Mon, 21 Nov 2022 15:14:39 +0200 Message-Id: <838rk44fgg.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 21 Nov 2022 01:17:02 +0200) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 21 Nov 2022 01:17:02 +0200 > Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net > From: Dmitry Gutov > > 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? It's discarded, as no longer needed. > 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? In my mental picture, the stack is not specific to a window, like it is today. > >> 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. It's a feature if you indeed want a separate stack in each window. What if you want the same stack in all of those windows? > 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. Not if I split that one window because I want to look at something else as well. > 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. When this becomes practical, we could try it and see if enough people like it. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 21:46:27 2022 Received: (at 59381) by debbugs.gnu.org; 22 Nov 2022 02:46:27 +0000 Received: from localhost ([127.0.0.1]:49284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxJIo-0000Va-Nr for submit@debbugs.gnu.org; Mon, 21 Nov 2022 21:46:27 -0500 Received: from mail-vs1-f54.google.com ([209.85.217.54]:34409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxJIm-0000VM-MT for 59381@debbugs.gnu.org; Mon, 21 Nov 2022 21:46:25 -0500 Received: by mail-vs1-f54.google.com with SMTP id i2so13195814vsc.1 for <59381@debbugs.gnu.org>; Mon, 21 Nov 2022 18:46:24 -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=ORn9uDLR7+9eHdpbd2gERLcRKO0qvHSdV/iuW0GYEEE=; b=MJpD12x3bhPWDn3EflJiuaDME/+Gf8Tf6DHpvSNnr7THwv0beCECzn/z5F1+2fso05 5B4HatNtIo7lGU85j2bb5xbNcp/Twv0uOgIlkFbD0Qs3tRHhEIlb2h7ZptO2tCNwUNK9 nhqs+iBlX2fAmf4E3q2hvXuM7U2ZISwD6SIWNXBh6fqkvXFO6gUCMDoKUa/AlG7f7xPB NBw9GqCa6e4jFKzuKjW/izCXQ6Of2FCG2uUdaNaxb728yvYbGV+eHyEGM2zTYXVGbC3/ vB+YsyJlLKACHCVlPc0SWu7JyhSm1Px/osMzeudp1K/YUligcciQ1mtnnTEPyF3QrERi +CLw== 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=ORn9uDLR7+9eHdpbd2gERLcRKO0qvHSdV/iuW0GYEEE=; b=shhxQnTXzR9gRSwleEbc7u0GNyovM3D6m7IXXqbJdawFvp9QLETW1tjF5EBet7m1dm QMy+ybbmVrUlUsQ+t/f3BBh23gVf656a28GjcVQlxNmkjBLzvOBqk/+Ne0E2atAM44Ly FAeUz4IhzXbHbclg/eg4L9CqC/ThqPEP0Q85yUfXY0LDbB4GYKKa7Y49UD7WnnwVhm+f 7Q2b7io7PoIwT6VUCeDbQZmagNil4dYPaTE02oOLgkw41PhmSynHcRQIQUkw13gOvL1P 2VV6s8O6zYclGLsY7ZfwDMHFE13tNX0tjC8RbmkdBTWxOmUhpz+06VfovQZGhL+JrteP 1Ieg== X-Gm-Message-State: ANoB5pmIlHAn/YK67BuBt+Gv5dOJv0K75Klc0LeMnfmeQcm97wb4C22F V/NsxZ4MLZ4S/ChVNnWkefEBJBL49LRafx3LAZY= X-Google-Smtp-Source: AA0mqf58zvIauQ+EiMTOgMbAkIIbCg6OVl8ZJTUpupDUZlQ9lUFRYm/f1D1xOAJ62vghpH96C1/17ZUv8SusE9pg57g= X-Received: by 2002:a67:fd09:0:b0:3af:ce07:c3d4 with SMTP id f9-20020a67fd09000000b003afce07c3d4mr2903138vsr.25.1669085178994; Mon, 21 Nov 2022 18:46:18 -0800 (PST) MIME-Version: 1.0 References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> In-Reply-To: <838rk44fgg.fsf@gnu.org> From: Ackerley Tng Date: Mon, 21 Nov 2022 18:46:07 -0800 Message-ID: Subject: Re: bug#59381: Should xref--marker-ring be per-window? To: Eli Zaretskii Content-Type: multipart/mixed; boundary="00000000000031d27705ee062de0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000031d27705ee062de0 Content-Type: text/plain; charset="UTF-8" Here's a patch for review! I made 'window-local the default storage so that we would hopefully get more feedback, do let me know if I should leave the default as 'global. On Mon, Nov 21, 2022 at 5:14 AM Eli Zaretskii wrote: > > > Date: Mon, 21 Nov 2022 01:17:02 +0200 > > Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net > > From: Dmitry Gutov > > > > 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? > > It's discarded, as no longer needed. > > > 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? > > In my mental picture, the stack is not specific to a window, like it is > today. > > > >> 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. > > It's a feature if you indeed want a separate stack in each window. What if > you want the same stack in all of those windows? > > > 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. > > Not if I split that one window because I want to look at something else as > well. > > > 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. > > When this becomes practical, we could try it and see if enough people like > it. --00000000000031d27705ee062de0 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Add-support-for-window-local-xref-history.patch" Content-Disposition: attachment; filename="0001-Add-support-for-window-local-xref-history.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_larm7npr0 RnJvbSAzMjk3YTBmZjAxNjM5NGRiYjc3NWNhZWIxOTRkMTVjNzU0YTIzOGRjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBY2tlcmxleSBUbmcgPGFja2VybGV5dG5nQGdvb2dsZS5jb20+ CkRhdGU6IE1vbiwgMjEgTm92IDIwMjIgMTg6Mzg6MDMgLTA4MDAKU3ViamVjdDogW1BBVENIXSBB ZGQgc3VwcG9ydCBmb3Igd2luZG93LWxvY2FsIHhyZWYgaGlzdG9yeQoKLS0tCiBsaXNwL3Byb2dt b2Rlcy94cmVmLmVsIHwgMTA2ICsrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgNzQgaW5zZXJ0aW9ucygrKSwgMzIgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvbGlzcC9wcm9nbW9kZXMveHJlZi5lbCBiL2xpc3AvcHJvZ21vZGVzL3hyZWYu ZWwKaW5kZXggODlhMDkwYWU5My4uMTIyYmY1NTU0MSAxMDA2NDQKLS0tIGEvbGlzcC9wcm9nbW9k ZXMveHJlZi5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy94cmVmLmVsCkBAIC00MjcsMzIgKzQyNyw3 MSBAQCB4cmVmLWF1dG8tanVtcC10by1maXJzdC14cmVmCiAgIDp2ZXJzaW9uICIyOC4xIgogICA6 cGFja2FnZS12ZXJzaW9uICcoeHJlZiAuICIxLjIuMCIpKQogCisoZGVmY3VzdG9tIHhyZWYtc3Rv cmFnZS10eXBlICd3aW5kb3ctbG9jYWwKKyAgIkhvdyB4cmVmIGhpc3RvcnkgaXMgc3RvcmVkLgor CitCZWZvcmUgRW1hY3MgMjkuMSwgeHJlZiBoaXN0b3J5IGlzIHN0b3JlZCBhdCB0aGUgZ2xvYmFs IGxldmVsLCBzbwordGhlIHNhbWUgaGlzdG9yeSBpcyB1c2VkIGFjcm9zcyB0aGUgZW50aXJlIEVt YWNzIGluc3RhbmNlLgorCitJbiBFbWFjcyAyOS4xIHRoZSBuZXcgZGVmYXVsdCBpcyB0byBoYXZl IG9uZSB4cmVmIGhpc3RvcnkgcGVyCit3aW5kb3csIHdoaWNoIGFsbG93cyB5b3UgdG8gbmF2aWdh dGUgY29kZSBpbmRlcGVuZGVudGx5IGluCitkaWZmZXJlbnQgd2luZG93cy4KKworQSBuZXcgeHJl ZiBoaXN0b3J5IGlzIGNyZWF0ZWQgZm9yIGV2ZXJ5IG5ldyB3aW5kb3cuIgorICA6dHlwZSAnKGNo b2ljZQorICAgICAgICAgIChjb25zdCA6dGFnICJQZXItd2luZG93IiB3aW5kb3ctbG9jYWwpCisg ICAgICAgICAgKGNvbnN0IDp0YWcgIkdsb2JhbCBoaXN0b3J5IGZvciBFbWFjcyBpbnN0YW5jZSIg Z2xvYmFsKSkKKyAgOnZlcnNpb24gIjI5LjEiCisgIDpwYWNrYWdlLXZlcnNpb24gJyh4cmVmIC4g IjEuNS4xIikpCisKIChtYWtlLW9ic29sZXRlLXZhcmlhYmxlICd4cmVmLS1tYXJrZXItcmluZyAn eHJlZi0taGlzdG9yeSAiMjkuMSIpCiAKIChkZWZ1biB4cmVmLXNldC1tYXJrZXItcmluZy1sZW5n dGggKF92YXIgX3ZhbCkKICAgKGRlY2xhcmUgKG9ic29sZXRlIG5pbCAiMjkuMSIpKQogICBuaWwp CiAKLShkZWZ2YXIgeHJlZi0taGlzdG9yeSAoY29ucyBuaWwgbmlsKQorKGRlZnVuIHhyZWYtLW1h a2UteHJlZi1oaXN0b3J5ICgpCisgICJSZXR1cm4gYSBuZXcgeHJlZiBoaXN0b3J5LiIKKyAgKGNv bnMgbmlsIG5pbCkpCisKKyhkZWZ2YXIgeHJlZi0taGlzdG9yeSAoeHJlZi0tbWFrZS14cmVmLWhp c3RvcnkpCiAgICIoQkFDS1dBUkQtU1RBQ0sgLiBGT1JXQVJELVNUQUNLKSBvZiBtYXJrZXJzIHRv IHZpc2l0ZWQgWHJlZiBsb2NhdGlvbnMuIikKIAorKGRlZnVuIHhyZWYtLWdldC1vci1jcmVhdGUt d2luZG93LXhyZWYtaGlzdG9yeSAoKQorICAiUmV0dXJuIHRoZSB4cmVmIGhpc3RvcnkgZm9yIHRo ZSBzZWxlY3RlZCB3aW5kb3cuCisKK0NyZWF0ZSBhbiB4cmVmIGhpc3RvcnkgYW5kIHJldHVybiBp dCBpZiBpdCBkaWQgbm90IGFscmVhZHkgZXhpc3QuIgorICAobGV0ICgodyAoc2VsZWN0ZWQtd2lu ZG93KSkpCisgICAgKGlmLWxldCAoKHIgKHdpbmRvdy1wYXJhbWV0ZXIgdyAneHJlZi0td2luZG93 LXhyZWYtaGlzdG9yeSkpKSByCisgICAgICAobGV0ICgoaCAoeHJlZi0tbWFrZS14cmVmLWhpc3Rv cnkpKSkKKyAgICAgICAgKHNldC13aW5kb3ctcGFyYW1ldGVyIHcgJ3hyZWYtLXdpbmRvdy14cmVm LWhpc3RvcnkgaCkpKSkpCisKKyhkZWZ1biB4cmVmLS1nZXQtaGlzdG9yeSAoKQorICAiUmV0dXJu IHhyZWYgaGlzdG9yeSBiYXNlZCBvbiBgeHJlZi1zdG9yYWdlLXR5cGUnLiIKKyAgKGNsLWNhc2Ug eHJlZi1zdG9yYWdlLXR5cGUKKyAgICAod2luZG93LWxvY2FsICh4cmVmLS1nZXQtb3ItY3JlYXRl LXdpbmRvdy14cmVmLWhpc3RvcnkpKQorICAgIChnbG9iYWwgeHJlZi0taGlzdG9yeSkpKQorCiAo ZGVmdW4geHJlZi0tcHVzaC1iYWNrd2FyZCAobSkKICAgIlB1c2ggbWFya2VyIE0gb250byB0aGUg YmFja3dhcmQgaGlzdG9yeSBzdGFjay4iCi0gICh1bmxlc3MgKGVxdWFsIG0gKGNhYXIgeHJlZi0t aGlzdG9yeSkpCi0gICAgKHB1c2ggbSAoY2FyIHhyZWYtLWhpc3RvcnkpKSkpCisgIChsZXQgKCho aXN0b3J5ICh4cmVmLS1nZXQtaGlzdG9yeSkpKQorICAgICh1bmxlc3MgKGVxdWFsIG0gKGNhYXIg aGlzdG9yeSkpCisgICAgICAocHVzaCBtIChjYXIgaGlzdG9yeSkpKSkpCiAKIChkZWZ1biB4cmVm LS1wdXNoLWZvcndhcmQgKG0pCiAgICJQdXNoIG1hcmtlciBNIG9udG8gdGhlIGZvcndhcmQgaGlz dG9yeSBzdGFjay4iCi0gICh1bmxlc3MgKGVxdWFsIG0gKGNhZHIgeHJlZi0taGlzdG9yeSkpCi0g ICAgKHB1c2ggbSAoY2RyIHhyZWYtLWhpc3RvcnkpKSkpCisgIChsZXQgKChoaXN0b3J5ICh4cmVm LS1nZXQtaGlzdG9yeSkpKQorICAgICh1bmxlc3MgKGVxdWFsIG0gKGNhZHIgaGlzdG9yeSkpCisg ICAgICAocHVzaCBtIChjZHIgaGlzdG9yeSkpKSkpCiAKIChkZWZ1biB4cmVmLXB1c2gtbWFya2Vy LXN0YWNrICgmb3B0aW9uYWwgbSkKICAgIkFkZCBwb2ludCBNIChkZWZhdWx0cyB0byBgcG9pbnQt bWFya2VyJykgdG8gdGhlIG1hcmtlciBzdGFjay4KIFRoZSBmdXR1cmUgc3RhY2sgaXMgZXJhc2Vk LiIKICAgKHhyZWYtLXB1c2gtYmFja3dhcmQgKG9yIG0gKHBvaW50LW1hcmtlcikpKQotICAoZG9s aXN0IChtayAoY2RyIHhyZWYtLWhpc3RvcnkpKQotICAgIChzZXQtbWFya2VyIG1rIG5pbCBuaWwp KQotICAoc2V0Y2RyIHhyZWYtLWhpc3RvcnkgbmlsKSkKKyAgKGxldCAoKGhpc3RvcnkgKHhyZWYt LWdldC1oaXN0b3J5KSkpCisgICAgKGRvbGlzdCAobWsgKGNkciBoaXN0b3J5KSkKKyAgICAgIChz ZXQtbWFya2VyIG1rIG5pbCBuaWwpKQorICAgIChzZXRjZHIgaGlzdG9yeSBuaWwpKSkKIAogOzs7 IyMjYXV0b2xvYWQKIChkZWZpbmUtb2Jzb2xldGUtZnVuY3Rpb24tYWxpYXMgJ3hyZWYtcG9wLW1h cmtlci1zdGFjayAjJ3hyZWYtZ28tYmFjayAiMjkuMSIpCkBAIC00NjIsMjkgKzUwMSwzMSBAQCB4 cmVmLWdvLWJhY2sKICAgIkdvIGJhY2sgdG8gdGhlIHByZXZpb3VzIHBvc2l0aW9uIGluIHhyZWYg aGlzdG9yeS4KIFRvIHVuZG8sIHVzZSBcXFt4cmVmLWdvLWZvcndhcmRdLiIKICAgKGludGVyYWN0 aXZlKQotICAoaWYgKG51bGwgKGNhciB4cmVmLS1oaXN0b3J5KSkKLSAgICAgICh1c2VyLWVycm9y ICJBdCBzdGFydCBvZiB4cmVmIGhpc3RvcnkiKQotICAgIChsZXQgKChtYXJrZXIgKHBvcCAoY2Fy IHhyZWYtLWhpc3RvcnkpKSkpCi0gICAgICAoeHJlZi0tcHVzaC1mb3J3YXJkIChwb2ludC1tYXJr ZXIpKQotICAgICAgKHN3aXRjaC10by1idWZmZXIgKG9yIChtYXJrZXItYnVmZmVyIG1hcmtlcikK LSAgICAgICAgICAgICAgICAgICAgICAgICAgICAodXNlci1lcnJvciAiVGhlIG1hcmtlZCBidWZm ZXIgaGFzIGJlZW4gZGVsZXRlZCIpKSkKLSAgICAgIChnb3RvLWNoYXIgKG1hcmtlci1wb3NpdGlv biBtYXJrZXIpKQotICAgICAgKHNldC1tYXJrZXIgbWFya2VyIG5pbCBuaWwpCi0gICAgICAocnVu LWhvb2tzICd4cmVmLWFmdGVyLXJldHVybi1ob29rKSkpKQorICAobGV0ICgoaGlzdG9yeSAoeHJl Zi0tZ2V0LWhpc3RvcnkpKSkKKyAgICAoaWYgKG51bGwgKGNhciBoaXN0b3J5KSkKKyAgICAgICAg KHVzZXItZXJyb3IgIkF0IHN0YXJ0IG9mIHhyZWYgaGlzdG9yeSIpCisgICAgICAobGV0ICgobWFy a2VyIChwb3AgKGNhciBoaXN0b3J5KSkpKQorICAgICAgICAoeHJlZi0tcHVzaC1mb3J3YXJkIChw b2ludC1tYXJrZXIpKQorICAgICAgICAoc3dpdGNoLXRvLWJ1ZmZlciAob3IgKG1hcmtlci1idWZm ZXIgbWFya2VyKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHVzZXItZXJyb3IgIlRo ZSBtYXJrZWQgYnVmZmVyIGhhcyBiZWVuIGRlbGV0ZWQiKSkpCisgICAgICAgIChnb3RvLWNoYXIg KG1hcmtlci1wb3NpdGlvbiBtYXJrZXIpKQorICAgICAgICAoc2V0LW1hcmtlciBtYXJrZXIgbmls IG5pbCkKKyAgICAgICAgKHJ1bi1ob29rcyAneHJlZi1hZnRlci1yZXR1cm4taG9vaykpKSkpCiAK IDs7OyMjI2F1dG9sb2FkCiAoZGVmdW4geHJlZi1nby1mb3J3YXJkICgpCiAgICJHb3QgdG8gdGhl IHBvaW50IHdoZXJlIGEgcHJldmlvdXMgXFxbeHJlZi1nby1iYWNrXSB3YXMgaW52b2tlZC4iCiAg IChpbnRlcmFjdGl2ZSkKLSAgKGlmIChudWxsIChjZHIgeHJlZi0taGlzdG9yeSkpCi0gICAgICAo dXNlci1lcnJvciAiQXQgZW5kIG9mIHhyZWYgaGlzdG9yeSIpCi0gICAgKGxldCAoKG1hcmtlciAo cG9wIChjZHIgeHJlZi0taGlzdG9yeSkpKSkKLSAgICAgICh4cmVmLS1wdXNoLWJhY2t3YXJkIChw b2ludC1tYXJrZXIpKQotICAgICAgKHN3aXRjaC10by1idWZmZXIgKG9yIChtYXJrZXItYnVmZmVy IG1hcmtlcikKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAodXNlci1lcnJvciAiVGhlIG1h cmtlZCBidWZmZXIgaGFzIGJlZW4gZGVsZXRlZCIpKSkKLSAgICAgIChnb3RvLWNoYXIgKG1hcmtl ci1wb3NpdGlvbiBtYXJrZXIpKQotICAgICAgKHNldC1tYXJrZXIgbWFya2VyIG5pbCBuaWwpCi0g ICAgICAocnVuLWhvb2tzICd4cmVmLWFmdGVyLXJldHVybi1ob29rKSkpKQorICAobGV0ICgoaGlz dG9yeSAoeHJlZi0tZ2V0LWhpc3RvcnkpKSkKKyAgICAoaWYgKG51bGwgKGNkciBoaXN0b3J5KSkK KyAgICAgICAgKHVzZXItZXJyb3IgIkF0IGVuZCBvZiB4cmVmIGhpc3RvcnkiKQorICAgICAgKGxl dCAoKG1hcmtlciAocG9wIChjZHIgaGlzdG9yeSkpKSkKKyAgICAgICAgKHhyZWYtLXB1c2gtYmFj a3dhcmQgKHBvaW50LW1hcmtlcikpCisgICAgICAgIChzd2l0Y2gtdG8tYnVmZmVyIChvciAobWFy a2VyLWJ1ZmZlciBtYXJrZXIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodXNlci1l cnJvciAiVGhlIG1hcmtlZCBidWZmZXIgaGFzIGJlZW4gZGVsZXRlZCIpKSkKKyAgICAgICAgKGdv dG8tY2hhciAobWFya2VyLXBvc2l0aW9uIG1hcmtlcikpCisgICAgICAgIChzZXQtbWFya2VyIG1h cmtlciBuaWwgbmlsKQorICAgICAgICAocnVuLWhvb2tzICd4cmVmLWFmdGVyLXJldHVybi1ob29r KSkpKSkKIAogKGRlZmluZS1vYnNvbGV0ZS12YXJpYWJsZS1hbGlhcwogICAneHJlZi0tY3VycmVu dC1pdGVtCkBAIC01MTAsMjIgKzU1MSwyMyBAQCB4cmVmLXB1bHNlLW1vbWVudGFyaWx5CiA7OyBl dGFncy5lbCBuZWVkcyB0aGlzCiAoZGVmdW4geHJlZi1jbGVhci1tYXJrZXItc3RhY2sgKCkKICAg IkRpc2NhcmQgYWxsIG1hcmtlcnMgZnJvbSB0aGUgeHJlZiBoaXN0b3J5LiIKLSAgKGRvbGlzdCAo bCAobGlzdCAoY2FyIHhyZWYtLWhpc3RvcnkpIChjZHIgeHJlZi0taGlzdG9yeSkpKQotICAgIChk b2xpc3QgKG0gbCkKLSAgICAgIChzZXQtbWFya2VyIG0gbmlsIG5pbCkpKQotICAoc2V0cSB4cmVm LS1oaXN0b3J5IChjb25zIG5pbCBuaWwpKQorICAobGV0ICgoaGlzdG9yeSAoeHJlZi0tZ2V0LWhp c3RvcnkpKSkKKyAgICAoZG9saXN0IChsIChsaXN0IChjYXIgaGlzdG9yeSkgKGNkciBoaXN0b3J5 KSkpCisgICAgICAoZG9saXN0IChtIGwpCisgICAgICAgIChzZXQtbWFya2VyIG0gbmlsIG5pbCkp KQorICAgIChzZXRxIGhpc3RvcnkgKGNvbnMgbmlsIG5pbCkpKQogICBuaWwpCiAKIDs7OyMjI2F1 dG9sb2FkCiAoZGVmdW4geHJlZi1tYXJrZXItc3RhY2stZW1wdHktcCAoKQogICAiV2hldGhlciB0 aGUgeHJlZiBiYWNrLWhpc3RvcnkgaXMgZW1wdHkuIgotICAobnVsbCAoY2FyIHhyZWYtLWhpc3Rv cnkpKSkKKyAgKG51bGwgKGNhciAoeHJlZi0tZ2V0LWhpc3RvcnkpKSkpCiA7OyBGSVhNRTogcmVu YW1lIHRoaXMgdG8gYHhyZWYtYmFjay1oaXN0b3J5LWVtcHR5LXAnLgogCiA7OzsjIyNhdXRvbG9h ZAogKGRlZnVuIHhyZWYtZm9yd2FyZC1oaXN0b3J5LWVtcHR5LXAgKCkKICAgIldoZXRoZXIgdGhl IHhyZWYgZm9yd2FyZC1oaXN0b3J5IGlzIGVtcHR5LiIKLSAgKG51bGwgKGNkciB4cmVmLS1oaXN0 b3J5KSkpCisgIChudWxsIChjZHIgKHhyZWYtLWdldC1oaXN0b3J5KSkpKQogDAogCiAoZGVmdW4g eHJlZi0tZ290by1jaGFyIChwb3MpCi0tIAoyLjM4LjEKCg== --00000000000031d27705ee062de0-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 23 22:16:17 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 03:16:17 +0000 Received: from localhost ([127.0.0.1]:56777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2in-0002zT-0v for submit@debbugs.gnu.org; Wed, 23 Nov 2022 22:16:17 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:38669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2ij-0002zC-3n for 59381@debbugs.gnu.org; Wed, 23 Nov 2022 22:16:15 -0500 Received: by mail-wr1-f54.google.com with SMTP id n3so597102wrp.5 for <59381@debbugs.gnu.org>; Wed, 23 Nov 2022 19:16:13 -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=JUNTkZ7ORc61k1fDlO9x+w3WK7e+MCRcHR4pvHcs3lU=; b=ZojZYqmmnArr62yP22nhAqebEzOIeN/E3V0sdgt5naEr3vAwkVAfF+YDd37EXK76JQ 90sNNe/L+vl6/nBjyhI5aWaKX8X0RMuNvgvM/XwBkBdkScpAWPy3+OKaIWgs6zJL5zwl EZDutNsvubSrMwLQvPJJJCen2BwaVXEnO5HNZ/mrbmjMXLFfnasF59THAP9axwTQ/+3P nU9pvoqvZiivgjUOKoumfCA9ynIjfNsqqlsTRQnAwY1ONU80U9dupZcTTU9nku3EtaEn B2IARUCvFz6xfvlJBe3ga2i6re5MxP1XHEy5XbHxQMWTOtyorjY2oUUopttMt5NXxaE2 q82A== 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=JUNTkZ7ORc61k1fDlO9x+w3WK7e+MCRcHR4pvHcs3lU=; b=1yRb9AC7T1BXkjwFHzntbQU++7FjYz1sTxhV91bpq0Sbv83WExuLJUdt1esFxH9qek bjEKB3SfauyCbdcOi4FTPLw4XcnmAOlnISXZAq+w+XBBK2CZAKEvO7PYkmRhUGinOC7f XoC/v2gqIkeyCGfmmsbyhJmwN1jDibWRDryDl+swiZNSVUSYRuz16No+A7uPwbv3YObE mp6Ze5DayoEjKvyClsl81HwSm86o6WPfoKXScC6hF1ETO5vbNyyZCosytE3kcIbyUxpT oKJyGnCem0a9asUd7w3069SSCKrtKv9DaDrVFS4D+Rud9MrbYRn+gByAcf1DNC6E8R+Y RFRA== X-Gm-Message-State: ANoB5pnGLwYsrVzuRbzDD4OMjPIfV+LTj14Muox06hedWoM+bPs5q/qm +JIwzTLmhjIuZxkmnpMw4NU= X-Google-Smtp-Source: AA0mqf4JiXhBB+4pBf/kbJxO9oSijiUDChg/oRyDi5Dw5loylToTYgJG94Ynozd96ollBD2Xg3UYBQ== X-Received: by 2002:adf:e8c7:0:b0:241:ea28:c4aa with SMTP id k7-20020adfe8c7000000b00241ea28c4aamr4105213wrn.81.1669259766962; Wed, 23 Nov 2022 19:16:06 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l22-20020a05600c4f1600b003cffd3c3d6csm194024wmq.12.2022.11.23.19.16.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Nov 2022 19:16:06 -0800 (PST) Message-ID: Date: Thu, 24 Nov 2022 05:16:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Juri Linkov References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <838rk66r17.fsf@gnu.org> <83y1s54jmj.fsf@gnu.org> <83r0xx4hb1.fsf@gnu.org> <864jus4y3b.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <864jus4y3b.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: Eli Zaretskii , Ackerley Tng , 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 21/11/22 09:42, Juri Linkov wrote: >>>> 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? >>> If this is optional and can be disabled, I don't think I mind. >> >> Definitely optional, we should provide different "storages" for >> this. Global (the current behavior), per-window, per-frame, maybe others. > > Also per-project (maybe even by default). I don't know whether I like that as default: some navigations could jump across projects, it would be weird to break the stacks along those boundaries. > PS: this whole subject of different xref stacks reminds me > trying to make sense of the different next-error stacks ;-) Definitely. ;-) From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 23 22:19:32 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 03:19:32 +0000 Received: from localhost ([127.0.0.1]:56781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2lv-00034A-Hr for submit@debbugs.gnu.org; Wed, 23 Nov 2022 22:19:32 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:46850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2lt-00033w-Gt for 59381@debbugs.gnu.org; Wed, 23 Nov 2022 22:19:30 -0500 Received: by mail-wr1-f53.google.com with SMTP id n7so561034wrr.13 for <59381@debbugs.gnu.org>; Wed, 23 Nov 2022 19:19:29 -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=pS50T9Mezu9LL5oD8LqnvEyw+kELx1HMzHMBm00V/+o=; b=aFH2SMOE8ubXlnRyjjRy0wgbqPDtzB9pMBICzwXcHRpk5KIJ/D8IW8HQdyTyOO0+vK Wqj9E5Oz0kBDPWuEx1zwxR2OnPp2b/KUp4tKwIn45FEzgccWMWEiqy26abULZgSY9tYx TTgGxfy16ObZuH1MXQsyaQWmC18HqbDYL/IAevzV5W1YoL3yKR+AS5CwZdYNVYoIcvjh SYlzk759EwXeKOEotlGEjFKWPq+JgNpt0J7Y9aG/5KHXzk3+1ofv+eip0hfT4EXpKwME vdDh73XrG6Undws39MCedJTr57jVBH/rl2nnOLOM/f9ZYF0ZhGK3Vc3ZHi78EOdPcgjD kHrA== 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=pS50T9Mezu9LL5oD8LqnvEyw+kELx1HMzHMBm00V/+o=; b=VCPF1F00ThGt1J39Tq4KjpeqOacMAXnqvMon8U7GJ/dT5RzgpKl4HeAImDd9gl+nin ZsXcddCYFfqvhsn1/Bxp2dBM3Le7x52kfqnOMOzHrjAiJhDlT9tk00I94XnPPQrp4YeR DuzS1gF2SZuIF3aJRc+lRmKmxZd8VsBCuF+Cpiry8bmD7gq/sSD9SqokVFisb5vNGZy1 RsdM7G+DK3ZZ1Pp+OUHn9wsT3nUlafmSgf5TeRnLHfnmPYfpHU/ZW84tlDRCd8bOu8NK fy21M3pE7viuv5esdzEzX1I9sSDeHCkIDMt2m8MpBxCoTvSmynV7mYBjzVMa6vfqnFEE 4m8g== X-Gm-Message-State: ANoB5pllD6kFmO3T3KjcePkrEpmOiix/G9dDepaJdDq3Oa43Rxy5Bcbf tQBCIcr+TT15Z2Wiw1EfZhIoM1Okhq8= X-Google-Smtp-Source: AA0mqf7QEGSjAU8k+N8x3c5pT0u14yRGoLFXiLlcvGFXQCA1w4OuNQFYiTeVVvAPutEvQktMIgcpYQ== X-Received: by 2002:a5d:5290:0:b0:241:cdd4:6925 with SMTP id c16-20020a5d5290000000b00241cdd46925mr12824425wrv.525.1669259963758; Wed, 23 Nov 2022 19:19:23 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g6-20020a5d5406000000b00241d2df4960sm76310wrv.17.2022.11.23.19.19.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Nov 2022 19:19:23 -0800 (PST) Message-ID: <7b2b0386-ae47-cdc5-d275-00a678c23b46@yandex.ru> Date: Thu, 24 Nov 2022 05:19:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Eli Zaretskii References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <838rk44fgg.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 21/11/22 15:14, Eli Zaretskii wrote: >> Date: Mon, 21 Nov 2022 01:17:02 +0200 >> Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net >> From: Dmitry Gutov >> >> On 20.11.2022 09:59, [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.53 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.53 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 21/11/22 15:14, Eli Zaretskii wrote: >> Date: Mon, 21 Nov 2022 01:17:02 +0200 >> Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net >> From: Dmitry Gutov >> >> 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? > > It's discarded, as no longer needed. That sounds odd. The idea regarding windows is about keeping multiple stacks at the same time, not about discarding information. >> 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? > > In my mental picture, the stack is not specific to a window, like it is > today. > >>>> 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. > > It's a feature if you indeed want a separate stack in each window. What if > you want the same stack in all of those windows? Maybe you never do? Or if you really do, that would require some additional manual management (through new commands, I suppose). >> 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. > > Not if I split that one window because I want to look at something else as > well. In my book that's starting a new line of thought, where it's okay to create a new stack. The old one is still around. >> 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. > > When this becomes practical, we could try it and see if enough people like > it. I don't know if it's practical or not, but it requires some additional design for sure. Maybe someday. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 23 22:29:10 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 03:29:10 +0000 Received: from localhost ([127.0.0.1]:56813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2vG-0003L2-6L for submit@debbugs.gnu.org; Wed, 23 Nov 2022 22:29:10 -0500 Received: from mail-wm1-f41.google.com ([209.85.128.41]:44000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy2vE-0003Km-63 for 59381@debbugs.gnu.org; Wed, 23 Nov 2022 22:29:08 -0500 Received: by mail-wm1-f41.google.com with SMTP id a11-20020a05600c2d4b00b003cf6f5fd9f1so358250wmg.2 for <59381@debbugs.gnu.org>; Wed, 23 Nov 2022 19:29:08 -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=ubCUg4diub33qUmIDya+YlQiY+VVHKhHSRKUO0Nkuyw=; b=Zlud9HwCdcOvnqvk0f49mG3T07bvAQsIxforCknPqkr5+jcIjssWVntANvXT4hN/s3 5mXnMy+4MeoHvSPHRe/YjCApFe4En+T8dyTIqAeIUEPOCWcZsWGikIRZ7oDpkFnaws9h nmfl+uRNlIF0h4VVXzYecsiHsbreNNXFL9RPdkSE2Qkpk/zU0K4fdGTf2YNc2cb7f4H7 0pjiC+NCUqlreANoSuGyc+nP+hWuurk3CcHomJOuedCW6vGJGHke0HdoePxDCPVp60R1 vmyfESswViuDVZ8EVwfWX6DI+u7sto+c/niZxesbd9aAwZBIhGRT5WblDG2f5o64A/ha vfdQ== 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=ubCUg4diub33qUmIDya+YlQiY+VVHKhHSRKUO0Nkuyw=; b=Zo1YxGyQBpe7TFLWMi9YT/86f8nDFLRbdLkQa/iwXjs0Qr0S4EM433bN6kPraIuu2I AQC1faVFsOFEIOSMNNzlSXY/dlnU7/9BghR+g6y0CaDEfJS7zuTCkazPht13rsot0pru mQGwGWuejxvffydCJiqHwjueakD9DF9fi2yJJQKp8Vj7FlL9UPvLz0cKkOw+ta7ObwFj cg7KnYVy6ojs1OiCZJfsrnRbMjwXnJYeHTvharHcl31w6CHHh10FzufBdFqhJaKm1YaJ lqctPW6UQ8bTZCW5KsT7ghCc+oq+sFq9hgbIzrDBAj+lzTB1JRQHjOWKMkZ15BEPgrC7 Cxhg== X-Gm-Message-State: ANoB5plgHlJvEwdT4oF0cdfXjogU3bA11yDfRqk/9Myabnn8kBMB9Kh4 W1/XomsHH3Xb+iItuxjFEHA= X-Google-Smtp-Source: AA0mqf53i73eViNmMwlcas9j96Q3yreYEyD31XcIppqHXleihHxp9NymMO5wyZEApE4ytDIWBHRWdg== X-Received: by 2002:a05:600c:43d6:b0:3d0:387d:8eb6 with SMTP id f22-20020a05600c43d600b003d0387d8eb6mr1257862wmn.137.1669260541913; Wed, 23 Nov 2022 19:29:01 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n6-20020a1ca406000000b003d005aab31asm3988548wme.40.2022.11.23.19.29.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Nov 2022 19:29:01 -0800 (PST) Message-ID: Date: Thu, 24 Nov 2022 05:28:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Ackerley Tng , Eli Zaretskii References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: 59381@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 22/11/22 04:46, Ackerley Tng wrote: > Here's a patch for review! It's reasonable, but what if we turn xref-storage-type into a variable that gets set to a function? One that knows how to retrieve and set the value. E.g.: (defcustom xref-storage-type 'xref-window-local-history ...) (defun xref-window-local-history (&optional new-value) (let ((w (selected-window))) (if new-value (set-window-parameter w 'xref--history new-value) (or (window-parameter w 'xref--history) (cons nil nil))))) (defun xref-global-history (&optional new-value) (if new-value (setq xref--history new-value) xref--history)) Then it will be trivial to extend with new storage mechanisms. > I made 'window-local the default storage so that we would hopefully > get more feedback, do let me know if I should leave the default as > 'global. That's not how we introduce changes here, with rare exceptions. window-local storage is going to be disruptive (I'm fairly sure), so let's keep the current behavior as default. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 02:30:29 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 07:30:30 +0000 Received: from localhost ([127.0.0.1]:57056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy6gn-0003X2-I2 for submit@debbugs.gnu.org; Thu, 24 Nov 2022 02:30:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy6gi-0003Wj-6e for 59381@debbugs.gnu.org; Thu, 24 Nov 2022 02:30:27 -0500 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 1oy6ga-00054i-4q; Thu, 24 Nov 2022 02:30:16 -0500 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=AjPK5jlOWH2D9oEn16WDVWnNVfdVslQCB0Kp1exWY0A=; b=nbbDtjsXFLkA zAkDL/o/IvU81VuwD/cODDU0OkX6Wag0urRj/F1pyH1hu7q+qVvlo6NE6N+GcrYnkMf8xqJ78gV0S x6rctSk8t+NEH6+rFgtByjQMpaoTnsnSyMnKqTfgHN8tJa609qiofBAMFmYRNA15NOlnwUFFY+RPE 9DOVFxMPtkDhmsB0A3DUEZcOSCD6Y9X+tXFDhorat4vWd1aIPxNxqtQdMe+dWY8BoYeV2K8pmRG9i CiaAJwZEExU14+Tcjl/SwaVbcDJ3AsDEOKB1FKna53zPVdQmdbBVq5yuKTJ+ApgQypFYN59Azu/b/ AaHh2gJZloCde31553LUCg==; 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 1oy6gZ-000225-9I; Thu, 24 Nov 2022 02:30:15 -0500 Date: Thu, 24 Nov 2022 09:30:34 +0200 Message-Id: <83a64gyfl1.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <7b2b0386-ae47-cdc5-d275-00a678c23b46@yandex.ru> (message from Dmitry Gutov on Thu, 24 Nov 2022 05:19:22 +0200) Subject: Re: bug#59381: Should xref--marker-ring be per-window? References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> <7b2b0386-ae47-cdc5-d275-00a678c23b46@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, ackerleytng@gmail.com, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 24 Nov 2022 05:19:22 +0200 > Cc: 59381@debbugs.gnu.org, ackerleytng@gmail.com, juri@linkov.net > From: Dmitry Gutov > > >>>> 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? > > > > It's discarded, as no longer needed. > > That sounds odd. The idea regarding windows is about keeping multiple > stacks at the same time, not about discarding information. My idea is not about windows, though. It's about a workflow that resembles searches: you keep searching for the same or similar strings as long as you are interested in a particular string/regexp; as long as you do that, using "C-s C-s" to repeat search, perhaps with minor edits of the search string, is what you want. Then, when you want another search, you discard the previous search string and start with a completely new 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. > > > > It's a feature if you indeed want a separate stack in each window. What if > > you want the same stack in all of those windows? > > Maybe you never do? Or if you really do, that would require some > additional manual management (through new commands, I suppose). I do that sometimes, not to rarely to remember it as a feature. That's why I suggested an explicit command, because I don't think Emacs can guess my intentions in this case. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 09:18:01 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 14:18:01 +0000 Received: from localhost ([127.0.0.1]:57783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyD3B-00065W-6C for submit@debbugs.gnu.org; Thu, 24 Nov 2022 09:18:01 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:40555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyD39-000659-CL for 59381@debbugs.gnu.org; Thu, 24 Nov 2022 09:17:59 -0500 Received: by mail-wr1-f54.google.com with SMTP id x5so2678287wrt.7 for <59381@debbugs.gnu.org>; Thu, 24 Nov 2022 06:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=/YQuN/oylS2oOTtdjitWVexPH9DHGSRw4MbGAegUShw=; b=ahAb7UhKjSyf8eodWiNbSqwOSTZ85eUDRZGNhnCp/N0EoihGu0cC8eh68VSZU4eJv3 2TmTfaRmSEwfvCs43K0OSVu6vRGbR4Ww0X8tK9gmUg7X0ASj07odjYTq90NqSPc0H4MD 6JlHtF9Cze1tBrvkKwxU9wVKA3REoFWoLD64Mnlk2AmWhdKOwXCniXtTv0U3k2pFuez5 pQDh2anVWmXZXxi+qX6Pyhck2IMzruVJ76ubyOzqNWmZ1qurxdZMfJvM0DM8tEKEo3Xd b5PDW5ksLzVLiXJr7Nv1spaB83PiIJhoxj5c65ruR8SELCE5wJTVkOMI2ocjff8ISmiv PjVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :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=/YQuN/oylS2oOTtdjitWVexPH9DHGSRw4MbGAegUShw=; b=a6XBZ7XFy6HVcX7l12OeQVNi2ag90ZrGc7ZAJAznwXxGNUKNieRfSO18ZIg8EWOuB4 AIBY0o7rG8xXqCCR/012Sx59Me2LJoz9rM+OYvVtwpxWbQ7tYbeT4FECbL1arCMhD+35 hXXsp01I+AbiCR69bop0+VSNJs21YOgLoP2vra/QlXhogimKsdyJ+bMxEjM9D+0CnsFT uuRef8mCPgD7WhE3pwXCCFR23hWFIG2PykNFOK1P2eWrOekFVTDTcPf6lT92UovfYXsb PTsoUrey3gJ7c83hdnpjkGKKlQp6Dvxjd6lXTRmnsTa8J0tz3A29u6rfOaKcQgUm9hRb 6ZUQ== X-Gm-Message-State: ANoB5pkVrBUyT1XmaKoyHKkYu0mk7+nF6SGR04tJ2UxK+/2Ii3bukRKW RYH5bJyoY+JbrKrHMxDCH50= X-Google-Smtp-Source: AA0mqf6rzgwj8zPvZNpufT6Tu9mLNXLvwrJyj2GbhgedyUYuyZDJfpY1dwctgTVexnKZ8i3T7NWShQ== X-Received: by 2002:adf:ea52:0:b0:241:b999:9e8f with SMTP id j18-20020adfea52000000b00241b9999e8fmr19260578wrn.151.1669299473693; Thu, 24 Nov 2022 06:17:53 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n12-20020a05600c3b8c00b003cfbbd54178sm13482747wms.2.2022.11.24.06.17.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Nov 2022 06:17:52 -0800 (PST) Message-ID: <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> Date: Thu, 24 Nov 2022 16:17:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US From: Dmitry Gutov To: Ackerley Tng , Eli Zaretskii References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: juri@linkov.net, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 24/11/22 05:28, Dmitry Gutov wrote: > (defcustom xref-storage-type 'xref-window-local-history Or rather: (defcustom xref-history-storage 'xref-window-local-history From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 18:42:39 2022 Received: (at 59381) by debbugs.gnu.org; 24 Nov 2022 23:42:40 +0000 Received: from localhost ([127.0.0.1]:60528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyLrb-0005NP-AI for submit@debbugs.gnu.org; Thu, 24 Nov 2022 18:42:39 -0500 Received: from mail-vs1-f44.google.com ([209.85.217.44]:38448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyLrZ-0005N7-7D for 59381@debbugs.gnu.org; Thu, 24 Nov 2022 18:42:38 -0500 Received: by mail-vs1-f44.google.com with SMTP id u124so2762722vsb.5 for <59381@debbugs.gnu.org>; Thu, 24 Nov 2022 15:42:37 -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=TafSLb7QsIQcB5cf/PFsp34dxCP/DceP1xYPh/KzLzg=; b=lyOedFjTovM46yp3/biVHVw/BgCgk4gRBCMvFF3+qbp63FuZ6MSdQiDKxH5/qF6vYh uvPi+QcR01SMvSpahc3LjH2yBN+fPvHeW5E5y00WNznCw4J9YydEqFoDzoWk30nBZfDW 6UUU8CVsRddbfu9Tu7aQcE9PKScNZZJCPqKXD3Wr+A4HTAlC7SFuYhtfm1BwirToR02m 358ngmnDt2XpYUxBL9RfPdjUx+NgNP3Poa267/8jmL9lJh92UjvhoVkvjBDm5Qk/fe4d uLZ6CI5m+Pz7iXhqY+Usq4AOim6z0+ti83o40SQ+1wSLasJmOD9P3h2MezUJD5qX6J2H XfCg== 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=TafSLb7QsIQcB5cf/PFsp34dxCP/DceP1xYPh/KzLzg=; b=V4g3J/awjnLAcvWJnsnemzAZCz9vPyI+IwmhR/JqGlpuU/2vGNn5A9F0jBiC/Z289+ Y33ap///5XPiXYLo20seQJqg04sgBrHNx5uBf5TvWovsKasz64toOU5XXekRwftDhP6u gJIOLpx1Gxt9Y+ln3I53PHqwirvqwpEsMMk9pOfKt8cbEY1bbCzN/KtoTvdOQgoCkhsv LmMmKD673YFzResBOSSM3zE9yq6YaS8nldvLhzVZznVhG/Tz0Mjlwl32Lvn/dw1oi3Px wJagHn8b+AEPZcunnrkHEZ3eY6yKT/iC1wy6r0dt7eyvVE/TvtflBgBV6vPb8J0Yaxe7 MQzA== X-Gm-Message-State: ANoB5pkymHuazZvhgXncYigfkQVJkLgu/6GvzPYveASnb0E9LQpsnjGJ JuYK8jsRANadX5RmWAmlQ3dVCrvPD7kOIWkO+Q4= X-Google-Smtp-Source: AA0mqf4HcbavXeo6ZGSdy0CH1eFghDDnadcnRnG7D0RYabC/w+un3yYjuuRacm8U0ER3Q/i9WFROmFl5/XGkhUfIl24= X-Received: by 2002:a67:ecd5:0:b0:3af:8e39:8868 with SMTP id i21-20020a67ecd5000000b003af8e398868mr9909542vsp.85.1669333351549; Thu, 24 Nov 2022 15:42:31 -0800 (PST) MIME-Version: 1.0 References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> In-Reply-To: <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> From: Ackerley Tng Date: Thu, 24 Nov 2022 15:42:19 -0800 Message-ID: Subject: Re: bug#59381: Should xref--marker-ring be per-window? To: Dmitry Gutov Content-Type: multipart/mixed; boundary="0000000000006e6cb505ee3ff592" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59381 Cc: Eli Zaretskii , juri@linkov.net, 59381@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000006e6cb505ee3ff592 Content-Type: text/plain; charset="UTF-8" > (defcustom xref-history-storage 'xref-window-local-history Here's an updated patch! On Thu, Nov 24, 2022 at 6:17 AM Dmitry Gutov wrote: > > On 24/11/22 05:28, Dmitry Gutov wrote: > > (defcustom xref-storage-type 'xref-window-local-history > > Or rather: > > (defcustom xref-history-storage 'xref-window-local-history --0000000000006e6cb505ee3ff592 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Add-support-for-window-local-xref-history.patch" Content-Disposition: attachment; filename="0001-Add-support-for-window-local-xref-history.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lavpyq940 RnJvbSA0Yzg5Njg1ZGM2ZDMyMzg5ZDdmMmE5MDUzNjcwYTE3NTExYjgzYjI5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBY2tlcmxleSBUbmcgPGFja2VybGV5dG5nQGdvb2dsZS5jb20+ CkRhdGU6IE1vbiwgMjEgTm92IDIwMjIgMTg6Mzg6MDMgLTA4MDAKU3ViamVjdDogW1BBVENIXSBB ZGQgc3VwcG9ydCBmb3Igd2luZG93LWxvY2FsIHhyZWYgaGlzdG9yeQoKLS0tCiBsaXNwL3Byb2dt b2Rlcy94cmVmLmVsIHwgMTE1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgODMgaW5zZXJ0aW9ucygrKSwgMzIgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvbGlzcC9wcm9nbW9kZXMveHJlZi5lbCBiL2xpc3AvcHJvZ21vZGVzL3hyZWYu ZWwKaW5kZXggZTIyMDM2N2EyMS4uNmYxMWQ2ZjRkNCAxMDA2NDQKLS0tIGEvbGlzcC9wcm9nbW9k ZXMveHJlZi5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy94cmVmLmVsCkBAIC00MjksMzIgKzQyOSw4 MCBAQCB4cmVmLWF1dG8tanVtcC10by1maXJzdC14cmVmCiAgIDp2ZXJzaW9uICIyOC4xIgogICA6 cGFja2FnZS12ZXJzaW9uICcoeHJlZiAuICIxLjIuMCIpKQogCisoZGVmY3VzdG9tIHhyZWYtaGlz dG9yeS1zdG9yYWdlICMneHJlZi13aW5kb3ctbG9jYWwtaGlzdG9yeQorICAiRnVuY3Rpb24gdGhh dCByZXR1cm5zIHhyZWYgaGlzdG9yeS4KKworVGhlIGZvbGxvd2luZyBmdW5jdGlvbnMgYXJlIHBy ZWRlZmluZWQ6CisKKy0gYHhyZWYtZ2xvYmFsLWhpc3RvcnknCisgICAgUmV0dXJuIGEgc2luZ2xl LCBnbG9iYWwgaGlzdG9yeSB1c2VkIGFjcm9zcyB0aGUgZW50aXJlIEVtYWNzCisgICAgaW5zdGFu Y2UuCistIGB4cmVmLXdpbmRvdy1sb2NhbC1oaXN0b3J5JworICAgIFJldHVybiBkaWZmZXJlbnQg eHJlZiBoaXN0b3JpZXMsIG9uZSBwZXIgd2luZG93LiAgQWxsb3dzIHlvdQorICAgIHRvIG5hdmln YXRlIGNvZGUgaW5kZXBlbmRlbnRseSBpbiBkaWZmZXJlbnQgd2luZG93cy4gIEEgbmV3CisgICAg eHJlZiBoaXN0b3J5IGlzIGNyZWF0ZWQgZm9yIGV2ZXJ5IG5ldyB3aW5kb3cuIgorICA6dHlwZSAn KHJhZGlvCisgICAgICAgICAgKGZ1bmN0aW9uLWl0ZW0gOnRhZyAiUGVyLXdpbmRvdyIgeHJlZi13 aW5kb3ctbG9jYWwtaGlzdG9yeSkKKyAgICAgICAgICAoZnVuY3Rpb24taXRlbSA6dGFnICJHbG9i YWwgaGlzdG9yeSBmb3IgRW1hY3MgaW5zdGFuY2UiIHhyZWYtZ2xvYmFsLWhpc3RvcnkpCisgICAg ICAgICAgKGZ1bmN0aW9uIDp0YWcgIk90aGVyIikpCisgIDp2ZXJzaW9uICIyOS4xIgorICA6cGFj a2FnZS12ZXJzaW9uICcoeHJlZiAuICIxLjUuMSIpKQorCiAobWFrZS1vYnNvbGV0ZS12YXJpYWJs ZSAneHJlZi0tbWFya2VyLXJpbmcgJ3hyZWYtLWhpc3RvcnkgIjI5LjEiKQogCiAoZGVmdW4geHJl Zi1zZXQtbWFya2VyLXJpbmctbGVuZ3RoIChfdmFyIF92YWwpCiAgIChkZWNsYXJlIChvYnNvbGV0 ZSBuaWwgIjI5LjEiKSkKICAgbmlsKQogCi0oZGVmdmFyIHhyZWYtLWhpc3RvcnkgKGNvbnMgbmls IG5pbCkKKyhkZWZ1biB4cmVmLS1tYWtlLXhyZWYtaGlzdG9yeSAoKQorICAiUmV0dXJuIGEgbmV3 IHhyZWYgaGlzdG9yeS4iCisgIChjb25zIG5pbCBuaWwpKQorCisoZGVmdmFyIHhyZWYtLWhpc3Rv cnkgKHhyZWYtLW1ha2UteHJlZi1oaXN0b3J5KQogICAiKEJBQ0tXQVJELVNUQUNLIC4gRk9SV0FS RC1TVEFDSykgb2YgbWFya2VycyB0byB2aXNpdGVkIFhyZWYgbG9jYXRpb25zLiIpCiAKKyhkZWZ1 biB4cmVmLWdsb2JhbC1oaXN0b3J5ICgmb3B0aW9uYWwgbmV3LXZhbHVlKQorICAiUmV0dXJuIHRo ZSB4cmVmIGhpc3RvcnkgZ2xvYmFsIHRvIHRoaXMgRW1hY3MgaW5zdGFuY2UuCisKK092ZXJyaWRl IGV4aXN0aW5nIHZhbHVlIHdpdGggTkVXLVZBTFVFIGlmIE5FVy1WQUxVRSBpcyBzZXQuIgorICAo aWYgbmV3LXZhbHVlCisgICAgICAoc2V0cSB4cmVmLS1oaXN0b3J5IG5ldy12YWx1ZSkKKyAgICB4 cmVmLS1oaXN0b3J5KSkKKworKGRlZnVuIHhyZWYtd2luZG93LWxvY2FsLWhpc3RvcnkgKCZvcHRp b25hbCBuZXctdmFsdWUpCisgICJSZXR1cm4gd2luZG93LWxvY2FsIHhyZWYgaGlzdG9yeS4KKwor T3ZlcnJpZGUgZXhpc3RpbmcgdmFsdWUgd2l0aCBORVctVkFMVUUgaWYgTkVXLVZBTFVFIGlzIHNl dC4iCisgIChsZXQgKCh3IChzZWxlY3RlZC13aW5kb3cpKSkKKyAgICAoaWYgbmV3LXZhbHVlCisg ICAgICAgIChzZXQtd2luZG93LXBhcmFtZXRlciB3ICd4cmVmLS1oaXN0b3J5IG5ldy12YWx1ZSkK KyAgICAgIChvciAod2luZG93LXBhcmFtZXRlciB3ICd4cmVmLS1oaXN0b3J5KQorICAgICAgICAg IChzZXQtd2luZG93LXBhcmFtZXRlciB3ICd4cmVmLS1oaXN0b3J5ICh4cmVmLS1tYWtlLXhyZWYt aGlzdG9yeSkpKSkpKQorCisoZGVmdW4geHJlZi0tZ2V0LWhpc3RvcnkgKCkKKyAgIlJldHVybiB4 cmVmIGhpc3RvcnkgdXNpbmcgeHJlZi1oaXN0b3J5LXN0b3JhZ2UuIgorICAoZnVuY2FsbCB4cmVm LWhpc3Rvcnktc3RvcmFnZSkpCisKIChkZWZ1biB4cmVmLS1wdXNoLWJhY2t3YXJkIChtKQogICAi UHVzaCBtYXJrZXIgTSBvbnRvIHRoZSBiYWNrd2FyZCBoaXN0b3J5IHN0YWNrLiIKLSAgKHVubGVz cyAoZXF1YWwgbSAoY2FhciB4cmVmLS1oaXN0b3J5KSkKLSAgICAocHVzaCBtIChjYXIgeHJlZi0t aGlzdG9yeSkpKSkKKyAgKGxldCAoKGhpc3RvcnkgKHhyZWYtLWdldC1oaXN0b3J5KSkpCisgICAg KHVubGVzcyAoZXF1YWwgbSAoY2FhciBoaXN0b3J5KSkKKyAgICAgIChwdXNoIG0gKGNhciBoaXN0 b3J5KSkpKSkKIAogKGRlZnVuIHhyZWYtLXB1c2gtZm9yd2FyZCAobSkKICAgIlB1c2ggbWFya2Vy IE0gb250byB0aGUgZm9yd2FyZCBoaXN0b3J5IHN0YWNrLiIKLSAgKHVubGVzcyAoZXF1YWwgbSAo Y2FkciB4cmVmLS1oaXN0b3J5KSkKLSAgICAocHVzaCBtIChjZHIgeHJlZi0taGlzdG9yeSkpKSkK KyAgKGxldCAoKGhpc3RvcnkgKHhyZWYtLWdldC1oaXN0b3J5KSkpCisgICAgKHVubGVzcyAoZXF1 YWwgbSAoY2FkciBoaXN0b3J5KSkKKyAgICAgIChwdXNoIG0gKGNkciBoaXN0b3J5KSkpKSkKIAog KGRlZnVuIHhyZWYtcHVzaC1tYXJrZXItc3RhY2sgKCZvcHRpb25hbCBtKQogICAiQWRkIHBvaW50 IE0gKGRlZmF1bHRzIHRvIGBwb2ludC1tYXJrZXInKSB0byB0aGUgbWFya2VyIHN0YWNrLgogVGhl IGZ1dHVyZSBzdGFjayBpcyBlcmFzZWQuIgogICAoeHJlZi0tcHVzaC1iYWNrd2FyZCAob3IgbSAo cG9pbnQtbWFya2VyKSkpCi0gIChkb2xpc3QgKG1rIChjZHIgeHJlZi0taGlzdG9yeSkpCi0gICAg KHNldC1tYXJrZXIgbWsgbmlsIG5pbCkpCi0gIChzZXRjZHIgeHJlZi0taGlzdG9yeSBuaWwpKQor ICAobGV0ICgoaGlzdG9yeSAoeHJlZi0tZ2V0LWhpc3RvcnkpKSkKKyAgICAoZG9saXN0IChtayAo Y2RyIGhpc3RvcnkpKQorICAgICAgKHNldC1tYXJrZXIgbWsgbmlsIG5pbCkpCisgICAgKHNldGNk ciBoaXN0b3J5IG5pbCkpKQogCiA7OzsjIyNhdXRvbG9hZAogKGRlZmluZS1vYnNvbGV0ZS1mdW5j dGlvbi1hbGlhcyAneHJlZi1wb3AtbWFya2VyLXN0YWNrICMneHJlZi1nby1iYWNrICIyOS4xIikK QEAgLTQ2NCwyOSArNTEyLDMxIEBAIHhyZWYtZ28tYmFjawogICAiR28gYmFjayB0byB0aGUgcHJl dmlvdXMgcG9zaXRpb24gaW4geHJlZiBoaXN0b3J5LgogVG8gdW5kbywgdXNlIFxcW3hyZWYtZ28t Zm9yd2FyZF0uIgogICAoaW50ZXJhY3RpdmUpCi0gIChpZiAobnVsbCAoY2FyIHhyZWYtLWhpc3Rv cnkpKQotICAgICAgKHVzZXItZXJyb3IgIkF0IHN0YXJ0IG9mIHhyZWYgaGlzdG9yeSIpCi0gICAg KGxldCAoKG1hcmtlciAocG9wIChjYXIgeHJlZi0taGlzdG9yeSkpKSkKLSAgICAgICh4cmVmLS1w dXNoLWZvcndhcmQgKHBvaW50LW1hcmtlcikpCi0gICAgICAoc3dpdGNoLXRvLWJ1ZmZlciAob3Ig KG1hcmtlci1idWZmZXIgbWFya2VyKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICh1c2Vy LWVycm9yICJUaGUgbWFya2VkIGJ1ZmZlciBoYXMgYmVlbiBkZWxldGVkIikpKQotICAgICAgKGdv dG8tY2hhciAobWFya2VyLXBvc2l0aW9uIG1hcmtlcikpCi0gICAgICAoc2V0LW1hcmtlciBtYXJr ZXIgbmlsIG5pbCkKLSAgICAgIChydW4taG9va3MgJ3hyZWYtYWZ0ZXItcmV0dXJuLWhvb2spKSkp CisgIChsZXQgKChoaXN0b3J5ICh4cmVmLS1nZXQtaGlzdG9yeSkpKQorICAgIChpZiAobnVsbCAo Y2FyIGhpc3RvcnkpKQorICAgICAgICAodXNlci1lcnJvciAiQXQgc3RhcnQgb2YgeHJlZiBoaXN0 b3J5IikKKyAgICAgIChsZXQgKChtYXJrZXIgKHBvcCAoY2FyIGhpc3RvcnkpKSkpCisgICAgICAg ICh4cmVmLS1wdXNoLWZvcndhcmQgKHBvaW50LW1hcmtlcikpCisgICAgICAgIChzd2l0Y2gtdG8t YnVmZmVyIChvciAobWFya2VyLWJ1ZmZlciBtYXJrZXIpCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAodXNlci1lcnJvciAiVGhlIG1hcmtlZCBidWZmZXIgaGFzIGJlZW4gZGVsZXRlZCIp KSkKKyAgICAgICAgKGdvdG8tY2hhciAobWFya2VyLXBvc2l0aW9uIG1hcmtlcikpCisgICAgICAg IChzZXQtbWFya2VyIG1hcmtlciBuaWwgbmlsKQorICAgICAgICAocnVuLWhvb2tzICd4cmVmLWFm dGVyLXJldHVybi1ob29rKSkpKSkKIAogOzs7IyMjYXV0b2xvYWQKIChkZWZ1biB4cmVmLWdvLWZv cndhcmQgKCkKICAgIkdvdCB0byB0aGUgcG9pbnQgd2hlcmUgYSBwcmV2aW91cyBcXFt4cmVmLWdv LWJhY2tdIHdhcyBpbnZva2VkLiIKICAgKGludGVyYWN0aXZlKQotICAoaWYgKG51bGwgKGNkciB4 cmVmLS1oaXN0b3J5KSkKLSAgICAgICh1c2VyLWVycm9yICJBdCBlbmQgb2YgeHJlZiBoaXN0b3J5 IikKLSAgICAobGV0ICgobWFya2VyIChwb3AgKGNkciB4cmVmLS1oaXN0b3J5KSkpKQotICAgICAg KHhyZWYtLXB1c2gtYmFja3dhcmQgKHBvaW50LW1hcmtlcikpCi0gICAgICAoc3dpdGNoLXRvLWJ1 ZmZlciAob3IgKG1hcmtlci1idWZmZXIgbWFya2VyKQotICAgICAgICAgICAgICAgICAgICAgICAg ICAgICh1c2VyLWVycm9yICJUaGUgbWFya2VkIGJ1ZmZlciBoYXMgYmVlbiBkZWxldGVkIikpKQot ICAgICAgKGdvdG8tY2hhciAobWFya2VyLXBvc2l0aW9uIG1hcmtlcikpCi0gICAgICAoc2V0LW1h cmtlciBtYXJrZXIgbmlsIG5pbCkKLSAgICAgIChydW4taG9va3MgJ3hyZWYtYWZ0ZXItcmV0dXJu LWhvb2spKSkpCisgIChsZXQgKChoaXN0b3J5ICh4cmVmLS1nZXQtaGlzdG9yeSkpKQorICAgIChp ZiAobnVsbCAoY2RyIGhpc3RvcnkpKQorICAgICAgICAodXNlci1lcnJvciAiQXQgZW5kIG9mIHhy ZWYgaGlzdG9yeSIpCisgICAgICAobGV0ICgobWFya2VyIChwb3AgKGNkciBoaXN0b3J5KSkpKQor ICAgICAgICAoeHJlZi0tcHVzaC1iYWNrd2FyZCAocG9pbnQtbWFya2VyKSkKKyAgICAgICAgKHN3 aXRjaC10by1idWZmZXIgKG9yIChtYXJrZXItYnVmZmVyIG1hcmtlcikKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICh1c2VyLWVycm9yICJUaGUgbWFya2VkIGJ1ZmZlciBoYXMgYmVlbiBk ZWxldGVkIikpKQorICAgICAgICAoZ290by1jaGFyIChtYXJrZXItcG9zaXRpb24gbWFya2VyKSkK KyAgICAgICAgKHNldC1tYXJrZXIgbWFya2VyIG5pbCBuaWwpCisgICAgICAgIChydW4taG9va3Mg J3hyZWYtYWZ0ZXItcmV0dXJuLWhvb2spKSkpKQogCiAoZGVmaW5lLW9ic29sZXRlLXZhcmlhYmxl LWFsaWFzCiAgICd4cmVmLS1jdXJyZW50LWl0ZW0KQEAgLTUxMiwyMiArNTYyLDIzIEBAIHhyZWYt cHVsc2UtbW9tZW50YXJpbHkKIDs7IGV0YWdzLmVsIG5lZWRzIHRoaXMKIChkZWZ1biB4cmVmLWNs ZWFyLW1hcmtlci1zdGFjayAoKQogICAiRGlzY2FyZCBhbGwgbWFya2VycyBmcm9tIHRoZSB4cmVm IGhpc3RvcnkuIgotICAoZG9saXN0IChsIChsaXN0IChjYXIgeHJlZi0taGlzdG9yeSkgKGNkciB4 cmVmLS1oaXN0b3J5KSkpCi0gICAgKGRvbGlzdCAobSBsKQotICAgICAgKHNldC1tYXJrZXIgbSBu aWwgbmlsKSkpCi0gIChzZXRxIHhyZWYtLWhpc3RvcnkgKGNvbnMgbmlsIG5pbCkpCisgIChsZXQg KChoaXN0b3J5ICh4cmVmLS1nZXQtaGlzdG9yeSkpKQorICAgIChkb2xpc3QgKGwgKGxpc3QgKGNh ciBoaXN0b3J5KSAoY2RyIGhpc3RvcnkpKSkKKyAgICAgIChkb2xpc3QgKG0gbCkKKyAgICAgICAg KHNldC1tYXJrZXIgbSBuaWwgbmlsKSkpCisgICAgKHNldHEgaGlzdG9yeSAoY29ucyBuaWwgbmls KSkpCiAgIG5pbCkKIAogOzs7IyMjYXV0b2xvYWQKIChkZWZ1biB4cmVmLW1hcmtlci1zdGFjay1l bXB0eS1wICgpCiAgICJXaGV0aGVyIHRoZSB4cmVmIGJhY2staGlzdG9yeSBpcyBlbXB0eS4iCi0g IChudWxsIChjYXIgeHJlZi0taGlzdG9yeSkpKQorICAobnVsbCAoY2FyICh4cmVmLS1nZXQtaGlz dG9yeSkpKSkKIDs7IEZJWE1FOiByZW5hbWUgdGhpcyB0byBgeHJlZi1iYWNrLWhpc3RvcnktZW1w dHktcCcuCiAKIDs7OyMjI2F1dG9sb2FkCiAoZGVmdW4geHJlZi1mb3J3YXJkLWhpc3RvcnktZW1w dHktcCAoKQogICAiV2hldGhlciB0aGUgeHJlZiBmb3J3YXJkLWhpc3RvcnkgaXMgZW1wdHkuIgot ICAobnVsbCAoY2RyIHhyZWYtLWhpc3RvcnkpKSkKKyAgKG51bGwgKGNkciAoeHJlZi0tZ2V0LWhp c3RvcnkpKSkpCiAMCiAKIChkZWZ1biB4cmVmLS1nb3RvLWNoYXIgKHBvcykKLS0gCjIuMzguMQoK --0000000000006e6cb505ee3ff592-- From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 19:00:03 2022 Received: (at 59381) by debbugs.gnu.org; 25 Nov 2022 00:00:03 +0000 Received: from localhost ([127.0.0.1]:60550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyM8R-0005s5-AV for submit@debbugs.gnu.org; Thu, 24 Nov 2022 19:00:03 -0500 Received: from mail-wr1-f44.google.com ([209.85.221.44]:39842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyM8P-0005r4-Cz for 59381@debbugs.gnu.org; Thu, 24 Nov 2022 19:00:01 -0500 Received: by mail-wr1-f44.google.com with SMTP id x17so4556550wrn.6 for <59381@debbugs.gnu.org>; Thu, 24 Nov 2022 16:00:01 -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=4r6dpAhyaYhUkXI7ACtI4asr+7+HotSjCHENfSGphQw=; b=OtpN01DqmCJZK7CScu3d5jZDz9qivzlqgHEQDTknMSA/fc7DfaQZk7t/pj3e04+H0e 9DdSnfAF4oUjiJv3Dm+47/TwJneTzlhMl4geL37NdoOYI635QBNh9gMKS2wypAONXsvz 3Ku97R746gcwoio+h+Qon+UX9NdFMWprODNS04q7Iv56GdBdlHMfZNyZmpV967LQsSeG T+uZG5Z5y0LSgBIPVEok5nV/GM/+ST7QE1znVd/3OVJV/0MC1CkHarmle18g00npYb2A E45t/elK/0T/V7GcE0zOoK3ACh/MWuu/uqp2shvw+tvQdOm0j5qLBUZsTn0AvkSoOlaa phag== 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=4r6dpAhyaYhUkXI7ACtI4asr+7+HotSjCHENfSGphQw=; b=KUrgZx+SAwBe0QfQHRIRTkQ0w+HNArZ0TikK1sTIbdNsapRGOhWjnTpaiqX3EhvR/2 IIDKwWfowwCavUEkeCAFNJL7gweMVn7yMnOezbwUUu61R3JJMLM4uuhSHTo28HGWgFcu Gc7DwIUXYz8XYA/GRtJiNp7mEhTu34iTzw63laWhwlX/qREnD5v4T/BQ1V+gRmSfMZBg 7gU9x+r0RkjWyttKcge02bL3vMkWrNpJ+lr8VfAFaMtON9QloPKNn23JAl2ewLc83+IU d2x1J3RzivaQmZF00dxu5NAhZFDO/GV5B/EbEZd0VUtfw/VUtuQLPfP7h2ps3EFPbBd4 9aqA== X-Gm-Message-State: ANoB5plsdhdt1iAfiN1tqN3ttANZjqtIgwe5SjIK7r8CAF3nOfPAJQEd /hDYkFLqfgw6Bmn0XJNpqpI= X-Google-Smtp-Source: AA0mqf5vhUaKMzrJOTRljGpfqFQTop11syJq23uQafAbsQ0PH6LRoh7OTbTbLp+523JNDCZJYGnPOw== X-Received: by 2002:adf:f74d:0:b0:236:4e3c:7720 with SMTP id z13-20020adff74d000000b002364e3c7720mr21689592wrp.674.1669334395599; Thu, 24 Nov 2022 15:59:55 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id d8-20020a5d6dc8000000b002415dd45320sm2358023wrz.112.2022.11.24.15.59.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Nov 2022 15:59:54 -0800 (PST) Message-ID: <0bd4b2db-15cd-62e7-54f7-3eb26627e808@yandex.ru> Date: Fri, 25 Nov 2022 01:59:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Ackerley Tng References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381 Cc: Eli Zaretskii , 59381@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 25/11/22 01:42, Ackerley Tng wrote: >> (defcustom xref-history-storage 'xref-window-local-history > Here's an updated patch! Nice. :-) Seems good to go. How would you like to sign the copyright assignment papers for Emacs? Regarding the patch, I was a tad surprised that there is no use for the "setter" function of xref-history-store, but it makes sense given that the value cons serves as a pointer to the data structure which we modify in-place. Perhaps we should keep the setter option in the signature anyway, for someone to be able to reset the history. Or save and restore it. Hm. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 19:28:33 2022 Received: (at 59381) by debbugs.gnu.org; 25 Nov 2022 00:28:33 +0000 Received: from localhost ([127.0.0.1]:60583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyMa0-0000Ry-O1 for submit@debbugs.gnu.org; Thu, 24 Nov 2022 19:28:32 -0500 Received: from mail-vs1-f49.google.com ([209.85.217.49]:45931) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyMZy-0000Rg-1y for 59381@debbugs.gnu.org; Thu, 24 Nov 2022 19:28:30 -0500 Received: by mail-vs1-f49.google.com with SMTP id 128so2797333vsz.12 for <59381@debbugs.gnu.org>; Thu, 24 Nov 2022 16:28:30 -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=7v93/ghV4WVnzAYYOsCX1Kw33dDbIUr4NDtKrgi7+HI=; b=qeheJl9i574Gfkpitip4JFSKvLmJCMm9NB6ZGefcl8Cz+6DV7qNMxpgZ0MRh7K67PG KaZCQveA8vsGGkPCEtxAOenK6Opf3GXYVX1BFZBlcb7XQsCuur+U7lWnGDmWgwSL40kr 1T7KsGhho0eB61FYqDYhI3IQQD28pzfp3PWue+iX+lQOOkybTTEmVlysZMul3ohrOc/x gAGp2lkoOlFg7DEGopnyGO1z3gnTVKaUp44tpe4V0CZmoXXXY7lnE15r3H20E6lBH8P0 764SqtreNWw7hgU1JoKb+YWBKaLOHCSSqc+KVUG+TkCSd5+eu2xs1Kgei7zLprIQhUzl HMPg== 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=7v93/ghV4WVnzAYYOsCX1Kw33dDbIUr4NDtKrgi7+HI=; b=ewuZm9lKUMh3TKZ6Rybv7RGKWzYYhGZKumBZIkWERE6kzS0h7gw0xh95GpHpv021qE h0nWOel1/yWo0Ld7fcCtzke3lWkcrjFRjXnyKFQ20RBzItmade0RB9QhTN9PflxP/J8T Y1DmW+MDPt94UdIti2Se0pYnbQIgk5MyVxZ5zJO2OFOB7xX6P2YDwfOy2qSiAq6WVYYh NJWZa9+hUoJNVA+Xo9LkmekQYaZtXhyDL+Uv6CTcG1xtRWQjAbKGw36GnyrFfokcM1uB NoUkxA9TFlPvwYlacjzfZM5BYyIzXriMv9rdUxRFJdAjGoEY0FNI7/FUeUkbI6GeN8IV uGVg== X-Gm-Message-State: ANoB5pkONEk0JkjCLrFtXTImlGxPzyesDDfsoHr8+h5x8pNqf0RpYWYQ E6qfY7LmZ1lvayfNjNxv3JDOsBRxhgfXGnw8Cbw= X-Google-Smtp-Source: AA0mqf7N1dPzUsUTLhO1G6cOxvPphTeQ6L1+hg/X+quDXShLGcSkvOC1faJpTdMmm557Fw4xkBhXudxvs/J4ivL8pho= X-Received: by 2002:a05:6102:914:b0:3ac:6376:1e41 with SMTP id x20-20020a056102091400b003ac63761e41mr10499594vsh.80.1669336103016; Thu, 24 Nov 2022 16:28:23 -0800 (PST) MIME-Version: 1.0 References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> <0bd4b2db-15cd-62e7-54f7-3eb26627e808@yandex.ru> In-Reply-To: <0bd4b2db-15cd-62e7-54f7-3eb26627e808@yandex.ru> From: Ackerley Tng Date: Thu, 24 Nov 2022 16:28:11 -0800 Message-ID: Subject: Re: bug#59381: Should xref--marker-ring be per-window? To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59381 Cc: Eli Zaretskii , 59381@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I think we should keep the setter option in the signature too! Perhaps someone would want to copy/transfer the history from storage to storage. I made the commit with my @google.com email, I believe Google has already signed an agreement with the FSF for all staff. Is that okay? On Thu, Nov 24, 2022 at 3:59 PM Dmitry Gutov wrote: > > On 25/11/22 01:42, Ackerley Tng wrote: > >> (defcustom xref-history-storage 'xref-window-local-history > > Here's an updated patch! > > Nice. :-) Seems good to go. > > How would you like to sign the copyright assignment papers for Emacs? > > Regarding the patch, I was a tad surprised that there is no use for the > "setter" function of xref-history-store, but it makes sense given that > the value cons serves as a pointer to the data structure which we modify > in-place. > > Perhaps we should keep the setter option in the signature anyway, for > someone to be able to reset the history. Or save and restore it. Hm. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 24 20:02:37 2022 Received: (at 59381-done) by debbugs.gnu.org; 25 Nov 2022 01:02:37 +0000 Received: from localhost ([127.0.0.1]:60649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyN6z-0008A1-1t for submit@debbugs.gnu.org; Thu, 24 Nov 2022 20:02:37 -0500 Received: from mail-wm1-f48.google.com ([209.85.128.48]:35414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyN6x-00089o-VI for 59381-done@debbugs.gnu.org; Thu, 24 Nov 2022 20:02:36 -0500 Received: by mail-wm1-f48.google.com with SMTP id r9-20020a1c4409000000b003d02dd48c45so4719773wma.0 for <59381-done@debbugs.gnu.org>; Thu, 24 Nov 2022 17:02:35 -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=Tnni19tDJCV2nUtrWpqlpSFen+ZWDPchGv2TbfGM6DI=; b=TC+5ThLvPi2m6fWv6zAXLSQUIcVCwEUTZY+BEgdDBRxOjizJXs7pfohUlU5Ho1b1RW Ng5K34+9cLfpRdNZzjKATJRwmJ5NFazL8Q+Lg33w600+LsNhUTlWX/mAWXkHttBrg/lZ nr9Vuyj9x5v3RbRaNlTZSDtydquG46S3ofg4mdxueSR6qZOnybCc58I4bsduFdu/d6xK qYqhKnt253xJoVIo+BoiRBX/PPWzUtHV2KwGGBbuJAKEIx0KVNCFRB7GiB3/X5/w8t+P tRwd2DPY9Wcekj7dtYV9Ur8mVzIbVC4bdCD3G1mN0xPyY0LoRhalKwA0pFCKLRTvhJ1b WgEw== 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=Tnni19tDJCV2nUtrWpqlpSFen+ZWDPchGv2TbfGM6DI=; b=1wmmNvUZwAfbCqclr4PnUagpKiF6xd6OKjdOd6Rjp5uU2lvgmi8lr0SoyLoB/CnRBU gAObhgfQQ/cn7X7MsD7YHY06X++CWms4h7FDtO8dhTJH6WZbIbzCrRltiSKo9yLimIzd b/xdut/Wj7S/1jsKbNlGJbEHDCwz+P6MuGga2/HtT2/P/J+MAa0XQ1A2Tv+Bgv+9GqmC EvuiS5XewFOSa979PXsH7bFyfadcw4xpYPKrTrh1D1FOeBJUPG3BqSnNP2mUooVHNRnL Edwr9OfeVsAJolrFUXSSd8VQxxJI2Xs/YQjTkpDpnAjpyYV1z3mIquUQAqsmYe0nawHV dUcA== X-Gm-Message-State: ANoB5pkKqXFVsU/9eX1+lxQEXPP7uWPWacdiGOyNey66A76xwZjW5DJ4 NMAATSJr8Qa+ZlcN7fvnBj8= X-Google-Smtp-Source: AA0mqf5IcPk/md/V9MFbA5DVtGSlVOhdNaKzihmaNQOtCu4EVexbkDBjERCeOAXcD7pkAAY66ZAdwA== X-Received: by 2002:a05:600c:3647:b0:3b4:c00d:2329 with SMTP id y7-20020a05600c364700b003b4c00d2329mr14624652wmq.124.1669338149930; Thu, 24 Nov 2022 17:02:29 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x7-20020adfdcc7000000b002366d1cc198sm2541545wrm.41.2022.11.24.17.02.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Nov 2022 17:02:29 -0800 (PST) Message-ID: Date: Fri, 25 Nov 2022 03:02:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#59381: Should xref--marker-ring be per-window? Content-Language: en-US To: Ackerley Tng References: <86leo6ai85.fsf@mail.linkov.net> <83leo67mbt.fsf@gnu.org> <83v8na5a5e.fsf@gnu.org> <838rk44fgg.fsf@gnu.org> <90fccc99-14e1-80f7-5179-62c44c1833b8@yandex.ru> <0bd4b2db-15cd-62e7-54f7-3eb26627e808@yandex.ru> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 59381-done Cc: 59381-done@debbugs.gnu.org, Eli Zaretskii , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 25/11/22 02:28, Ackerley Tng wrote: > I think we should keep the setter option in the signature too! Perhaps > someone would want to copy/transfer the history from storage to > storage. Deal! > I made the commit with my @google.com email, I believe Google has > already signed an agreement with the FSF for all staff. Is that okay? Ah yep, that probably works. I've pushed the patch with minor updates in 65f35b7f6f4 and bumped xref version to 1.6.0. Also see the commit message for an example of how we write them, for your next contribution. Thanks! From unknown Fri Aug 15 20:54:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 23 Dec 2022 12:24:23 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator