Received: (at 63829) by debbugs.gnu.org; 17 Aug 2023 02:14:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 16 22:14:15 2023
Received: from localhost ([127.0.0.1]:42401 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qWSWd-0002NL-EV
for submit <at> debbugs.gnu.org; Wed, 16 Aug 2023 22:14:15 -0400
Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52365)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qWSWb-0002N4-0V
for 63829 <at> debbugs.gnu.org; Wed, 16 Aug 2023 22:14:14 -0400
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.nyi.internal (Postfix) with ESMTP id AB5395C00BA;
Wed, 16 Aug 2023 22:14:07 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Wed, 16 Aug 2023 22:14:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to; s=fm2; t=
1692238447; x=1692324847; bh=EnMBQH6omlO9XT7McfPgrqBaUygSM2GlmEN
fpCTV0KA=; b=Ew4uvdKIFTeaWjrsjln5c0mGxXTJ6Btrg5f54GG15MvyUCYU2eU
YLlWX4kc8Ve0eTI93x6EZhnj1KiTUDFcdQvwpdERa5OR0fz1Wam2OEuwvmWZ+PoX
5RlPl/eKVvFihEbgzZCBWu6jUSIJyq3CtbQTQF13rCOHuu/oqsTIlSlyNPgHTARR
iqq2DGm6CB5eVOZUCFoJiAdYUQct9lYBfUsbizwY/TpcUsQ5S8Y284OzNiLybwTx
Iw2kgqDYRv9cxs+EKSrjbttF6zM5rCi9LCv/te6ovH0A3h2phnDJe/P9Mhx2OwUk
IF9lXhWrTUojRB63IoOj973zGMKiYzVH3QQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1692238447; x=1692324847; bh=EnMBQH6omlO9XT7McfPgrqBaUygSM2GlmEN
fpCTV0KA=; b=X5B1Xr0zAXmlDBHWay94uxc8xrn2mR7UdT1x7Ph34a0PnYGaB1K
LGTDty9AGowPQxJr/4FdwrQrSsdWCFnbBrNGeikplvfNscSBJnQMBVIJGCy3doTM
pc9HbsjFiPtguux3U2AmSOPxhiATnjpCbDgDiPRqsAx/nRsFn7HGbdokjMQEJ168
og0dmSi/we0MpxuTmb4ZRmD+h6NzaU74/MZW69KcFQXbHps5vTLBIHZ3UWXHJn/p
di6zKRwmpkto8rGDZ22c8aLYZu7lABdf5OdtnCXmVtNB0ja5lDQYZq1OAGO5eLZI
ipnCpWdJsvpM8ZJWqRfvhuq8gyVdY9vpq7Q==
X-ME-Sender: <xms:b4LdZML9QoTAvXww2JgMxyyOPgfxeMIQp9QY_xa7YZPsy_t-h8o-Xg>
<xme:b4LdZMJzUPM0_XnFFmGiwtHO41EKbHtlIdLoAZ4YCQuWnGYjBPAuD0yQdArbcXts6
914Gd0sG-gNsQnx4z8>
X-ME-Received: <xmr:b4LdZMvtectXRoYcobpMMo1TVLEpRXBf9i5E1xwE-fqbPz-DgL7ofdpkt2KaJ68>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddutddgheejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel
vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:b4LdZJYNlrQY0DR3emwV3EWyHpOErmOg9SMPEsh4DyviS0ZQi0zvsQ>
<xmx:b4LdZDZRpIpoiSLVNWJ_f2wZjVwvEifPyZi6-4QDSlbVCbvdzwPing>
<xmx:b4LdZFC0m9tBb71_LuZ2USEZiha5bwet5bI9mgeW-HPIVODFgrqZkA>
<xmx:b4LdZCkPOPH1WBD8fCNeqYOCRFuOMcviCqYtBTn2MNB2_bryi60Ktg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
16 Aug 2023 22:14:06 -0400 (EDT)
Message-ID: <f447ea97-c299-1a53-465d-063690e717d9@HIDDEN>
Date: Thu, 17 Aug 2023 05:14:03 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
with common-parent-directory
Content-Language: en-US
To: sbaugh@HIDDEN
References: <ierpm6ezude.fsf@HIDDEN>
<16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN>
<ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN>
<3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN>
<iersfb48u0g.fsf@HIDDEN>
<d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN>
<ier350lqt77.fsf@HIDDEN> <87a5uti6mo.fsf@HIDDEN>
<73a695f3-7c6a-0e50-41dd-61f8269f6ecf@HIDDEN> <875y5fitiq.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <875y5fitiq.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.7 (-)
X-Debbugs-Envelope-To: 63829
Cc: Spencer Baugh <sbaugh@HIDDEN>, Juri Linkov <juri@HIDDEN>,
63829 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.7 (--)
On 16/08/2023 05:57, sbaugh@HIDDEN wrote:
>> Now that you can have this additional capability as an option, do you
>> think you will be using it as well?
>
> Yes, probably I will enable this shared project history mode for my
> users.
Nice.
>> Before we do that, small (or not so small) question: do you think we
>> should test that the current buffer exists in the other project too?
>> We could do that with file-exists-p (but that's an extra round-trip
>> over Tramp), or by checking against the full list like in below.
>
> No, I don't think that's necessary. It produces more consistent
> behavior to not check whether the file exists. And anyway, it could
> maybe be helpful to be able to create the same file in another project.
Fair point. Creating new files it is, then.
>> Relatedly, with the cross-project history, we should ask the same
>> question: will we check that the "transplanted" history entries
>> correspond to existing files in the other project (and filter out
>> those that don't).
>
> Likewise I don't think that's necessary.
>
> Although it might be nice to support a user-supplied predicate which,
> given the current project and a path in the history (which contains as a
> property the originating project), determines whether to show that path.
> Then the user could filter the history to only paths in "sibling
> projects" with similar content. Not required though.
OK, we can easily add such a predicate later, if somebody asks.
I'm pushed the first of your patches, but the second needed some
adjustments. Chiefly because we need to make sure it works with any
value of project-read-file-name-function, so the impl can't be
concentrated in just one of them.
Check out the amended patch below. Any suggestions on how to do it more
elegantly (without duplicating the add-to-history call) are welcome too.
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index e1d14474323..d810d8d9605 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1046,6 +1046,13 @@ project-read-file-name-function
:group 'project
:version "27.1")
+(defun project--expand-file-name (filename project)
+ (when-let ((old-root (get-text-property 0 'project filename)))
+ (abbreviate-file-name
+ (expand-file-name
+ (file-relative-name filename old-root)
+ (project-root project)))))
+
(defun project--read-file-cpd-relative (prompt
all-files &optional predicate
hist mb-default)
@@ -1124,9 +1131,18 @@ project-find-file-in
dirs)
(project-files project dirs)))
(completion-ignore-case read-file-name-completion-ignore-case)
- (file (funcall project-read-file-name-function
- "Find file" all-files nil 'file-name-history
- suggested-filename)))
+ (file
+ (let ((file-name-history (mapcar
+ (lambda (f)
+ (or (project--expand-file-name f
project) f))
+ file-name-history)))
+ (funcall project-read-file-name-function
+ "Find file" all-files nil 'file-name-history
+ suggested-filename))))
+ (when history-add-new-input
+ ;; Have to re-add it here because of the let-binding above.
+ (add-to-history 'file-name-history
+ (propertize file 'project (project-root project))))
(if (string= file "")
(user-error "You didn't specify the file")
(find-file file))))
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 16 Aug 2023 02:57:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 15 22:57:29 2023 Received: from localhost ([127.0.0.1]:38513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qW6iu-0003vf-P3 for submit <at> debbugs.gnu.org; Tue, 15 Aug 2023 22:57:29 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:32854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bounces+21787432-9ab0-63829=debbugs.gnu.org@HIDDEN>) id 1qW6iq-0003vP-89 for 63829 <at> debbugs.gnu.org; Tue, 15 Aug 2023 22:57:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=gvSweho3ui0qBBft6GoIP8WG893ZTVBvCqBL8WdFow8=; b=etAS/yQ/X+KXU4HZvHu/yYqjBC3IXRo3LVZTtxRv6UwwHPXvRhry17j4Cabvgpm/IifC ltg5aZCjqx9qrBa1P8RBdgSokwdqsXUCJ2Xly2j25uHEoY3beG6OFgYdqW/ZrDc8Gw7Frr OFdbFE1fTA+tlLK2zgIUhqkm9ng6IwBbSUXBcef1QkA9tmaOWjIsyspxgIyWozL4Pbrv3+ UZN+cgxJZGtbKQZx1J8buaqfdtSUGAFEuqFA4OCehZBZTywF4MTagVGjiI8ZuvJWGgAepG neZBjDyInNX3AI+2cuN+vOBNMbwuLh2oMvxy+Z8TmtWrC4Kyw7uhlhjvY6Jcs3FA== Received: by filterdrecv-77869f68cc-kmpqh with SMTP id filterdrecv-77869f68cc-kmpqh-1-64DC3B0E-15 2023-08-16 02:57:18.771875764 +0000 UTC m=+8392879.067187345 Received: from earth.catern.com (unknown) by geopod-ismtpd-13 (SG) with ESMTP id Negeix6wRhaKr7yQ7UckhA Wed, 16 Aug 2023 02:57:18.672 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@HIDDEN; receiver=gutov.dev Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 05C8F60155; Tue, 15 Aug 2023 22:57:17 -0400 (EDT) From: sbaugh@HIDDEN Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory In-Reply-To: <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@HIDDEN> (Dmitry Gutov's message of "Wed, 16 Aug 2023 04:49:58 +0300") References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> <iersfb48u0g.fsf@HIDDEN> <d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN> <ier350lqt77.fsf@HIDDEN> <87a5uti6mo.fsf@HIDDEN> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@HIDDEN> Date: Wed, 16 Aug 2023 02:57:18 +0000 (UTC) Message-ID: <875y5fitiq.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbKwY9OkpHA7ZJoTPPRPN7?= =?us-ascii?Q?WFzyWwRgn8o5EcFoOV9dJtVvArnnou26AXIooRG?= =?us-ascii?Q?LSszh820s1wxxqDgnNSG=2FhLgbUeSnehhQrQJsWu?= =?us-ascii?Q?Mva2PrMKIJnPtLhXt8AyYcuXc=2FoIOBOkXpph5Ni?= =?us-ascii?Q?3ab0BhG3xmAU3TP4VTPtKUS1XJY8OWKppjw=3D=3D?= To: Dmitry Gutov <dmitry@HIDDEN> X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii 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: Dmitry Gutov <dmitry@HIDDEN> writes: > On 15/08/2023 01:47, sbaugh@HIDDEN wrote: > >>>>> I'm not sure I understand the alternative - the idea would be to share >>>>> project file name history b [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <https://www.spamcop.net/bl.shtml?149.72.123.24>] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.123.24 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: 63829 Cc: Spencer Baugh <sbaugh@HIDDEN>, Juri Linkov <juri@HIDDEN>, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.2 (/) Dmitry Gutov <dmitry@HIDDEN> writes: > On 15/08/2023 01:47, sbaugh@HIDDEN wrote: > >>>>> I'm not sure I understand the alternative - the idea would be to share >>>>> project file name history between all projects? I guess that could be >>>>> nice, although I don't personally use file name history that much, and >>>>> AFAIK it wouldn't solve any concrete user problems, so I'm not really >>>>> motivated to implement it. >>>> >>>> The alternative is a little more general, e.g. propertize every such >>>> history entry with the value of the root, so that they can be >>>> post-processed to adapt to any other root directory. >>>> >>>> This shouldn't take too much work, actually. But I don't know if that >>>> is indeed a necessary feature. From the discussion >>>> (https://debbugs.gnu.org/58447), I had been under impression that it >>>> would be wanted, but it might be just "nice to have". >>> >>> I would be happy to do that. That sounds very cool actually. >>> >>> Can you elaborate on how exactly you imagine this happening? I guess, >>> every time someone enters a filename with project-find-file or >>> project-find-dir, we would include a propertized version of that >>> filename in file-name-history? And then we would re-relativize them and >>> adapt them to the current project when including them as history? >> Okay, I did that. Extremely rough patch follows. > > Thanks! It's very close to what I was thinking of (modulo some > cosmetics and perf optimizations). > >> Btw, the reason I'm interested in this shared project history is because >> our workflow involves creating many new projects (one per branch); so >> mostly each project has no history at all, and sharing history between >> projects is the only way to get any. > > Now that you can have this additional capability as an option, do you > think you will be using it as well? Yes, probably I will enable this shared project history mode for my users. >> But, it seems to me that this doesn't really help with having the >> current file be "future history". That's still useful when switching >> between similar projects. And all the logic of my other patch which >> does that, is still required with this patch. > > Indeed, that's a good point. So I think we'll install your first patch > either way. > > Before we do that, small (or not so small) question: do you think we > should test that the current buffer exists in the other project too? > We could do that with file-exists-p (but that's an extra round-trip > over Tramp), or by checking against the full list like in below. No, I don't think that's necessary. It produces more consistent behavior to not check whether the file exists. And anyway, it could maybe be helpful to be able to create the same file in another project. > Relatedly, with the cross-project history, we should ask the same > question: will we check that the "transplanted" history entries > correspond to existing files in the other project (and filter out > those that don't). Likewise I don't think that's necessary. Although it might be nice to support a user-supplied predicate which, given the current project and a path in the history (which contains as a property the originating project), determines whether to show that path. Then the user could filter the history to only paths in "sibling projects" with similar content. Not required though. > WDYT? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index d8b12c9c880..a32bc2dd8d3 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1116,7 +1116,10 @@ project-find-file-in > (completion-ignore-case read-file-name-completion-ignore-case) > (file (funcall project-read-file-name-function > "Find file" all-files nil 'file-name-history > - suggested-filename))) > + (if (file-name-absolute-p suggested-filename) > + (and (member suggested-filename all-files) > + suggested-filename) > + suggested-filename)))) > (if (string= file "") > (user-error "You didn't specify the file") > (find-file file))))
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.
Received: (at 63829) by debbugs.gnu.org; 16 Aug 2023 01:50:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 15 21:50:09 2023
Received: from localhost ([127.0.0.1]:38446 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qW5fk-0002GX-RQ
for submit <at> debbugs.gnu.org; Tue, 15 Aug 2023 21:50:09 -0400
Received: from out5-smtp.messagingengine.com ([66.111.4.29]:52965)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qW5fi-0002Fm-Fz
for 63829 <at> debbugs.gnu.org; Tue, 15 Aug 2023 21:50:07 -0400
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
by mailout.nyi.internal (Postfix) with ESMTP id C62B65C0338;
Tue, 15 Aug 2023 21:50:00 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute3.internal (MEProxy); Tue, 15 Aug 2023 21:50:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to; s=fm2; t=
1692150600; x=1692237000; bh=5xTRvPalSi+SBJ15QIoYxSf+MXESh9NqPxn
mddYKbL0=; b=CTBjcV8B7ccQ/kBfUZi6kxHQrjwxlWQGmtKczYRTxhKjTonqPZp
N9HmVeB2MOhwCq4LxXD0XJFGAn3WxkA51XtoXTmXQR62Dx+tQoCGeZl0XY6Re78K
vY89QZqI8nLBC6kGYFATWaP21M00xUA6mqMwtHoiE8vdgbtEpZhnqnjbdorvD+3J
ddWQjtUrmzch8c4r4MHivg1BfeOEXyX+AdIoapcmar+F037ovEnyajjLUg580Uf0
CoYkjF8FPtphj9boelAqheDv5HwaWBcd0TltkfAJrYXxZIk/WDk2m9EhQpyVs0Xc
M2380xaz6uInLUFj7iuQhraOiggpDKAMAfA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1692150600; x=1692237000; bh=5xTRvPalSi+SBJ15QIoYxSf+MXESh9NqPxn
mddYKbL0=; b=iK+t20tkzsFpTVJyzcd4aZ9nsk65zsOc0m2XOVE0wOm8dhOQXiL
jA0V24nqRUHvmY9Yva+Cb/y7xHIFMhoFe39zhA7bzhE3L9AocIQORIME/Fe3wmPG
JwZMGOFR7yD6w57QN9nlSR679Md+RJEdq2+MzXzOFWQ0mplAui7jiyjvZu9HJ+TD
oflB8mQvZsmr3Ef2J1H32TfJNUbaY+YUIRSP7UQSUw0tX6a1VktZGXV1rbQjJFss
vYxslbPG6N7T46uLY7xNkM+i9OnoeTDpP8M/jXPfhZWH25AJlJ+fcjD8/usHaMtV
a0H7sMZ8C0Z1I/BS+DZmNwCCH2fz4NhPHSA==
X-ME-Sender: <xms:SCvcZEWhSpFIkHlB4AieIusSj-SHXtwZPbXKoQaStyNB-llVc6etNQ>
<xme:SCvcZInEPLOiZUvjF7HSN7KYVT-GiKMqPKs2GsfEshe1bG0LX3eZcIYCZMjAnVMEc
4Q9BAoYmsYokqf-Dgk>
X-ME-Received: <xmr:SCvcZIYcH904F8A-3Yh7rl8YHRC5l5hShCsiwcmVGT7r1ijAzxY6h9qDPtZxTtQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtkedgheduucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv
jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc
frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:SCvcZDX1St5kdHny2iEhRvA9yDNzrYX5rKjlHvbNGgMVkrv32KK8Cg>
<xmx:SCvcZOnJVz13Idt9RwDMfizO-3o7ZGNvlMc4oPfoXQiwZc4ddhoPlg>
<xmx:SCvcZIfqeq_Y-Lt8eY7mQXWR0KLIELPxdQdr2FwSMxaFgAyqaN614g>
<xmx:SCvcZDzLMBGTTa29XEwLxujsf_E6kEPTILVoiX-aqXz0KTORQSVZ0w>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
15 Aug 2023 21:49:59 -0400 (EDT)
Message-ID: <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@HIDDEN>
Date: Wed, 16 Aug 2023 04:49:58 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
with common-parent-directory
Content-Language: en-US
To: sbaugh@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>
References: <ierpm6ezude.fsf@HIDDEN>
<16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN>
<ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN>
<3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN>
<iersfb48u0g.fsf@HIDDEN>
<d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN>
<ier350lqt77.fsf@HIDDEN> <87a5uti6mo.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <87a5uti6mo.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.7 (-)
X-Debbugs-Envelope-To: 63829
Cc: 63829 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.7 (--)
On 15/08/2023 01:47, sbaugh@HIDDEN wrote:
>>>> I'm not sure I understand the alternative - the idea would be to share
>>>> project file name history between all projects? I guess that could be
>>>> nice, although I don't personally use file name history that much, and
>>>> AFAIK it wouldn't solve any concrete user problems, so I'm not really
>>>> motivated to implement it.
>>>
>>> The alternative is a little more general, e.g. propertize every such
>>> history entry with the value of the root, so that they can be
>>> post-processed to adapt to any other root directory.
>>>
>>> This shouldn't take too much work, actually. But I don't know if that
>>> is indeed a necessary feature. From the discussion
>>> (https://debbugs.gnu.org/58447), I had been under impression that it
>>> would be wanted, but it might be just "nice to have".
>>
>> I would be happy to do that. That sounds very cool actually.
>>
>> Can you elaborate on how exactly you imagine this happening? I guess,
>> every time someone enters a filename with project-find-file or
>> project-find-dir, we would include a propertized version of that
>> filename in file-name-history? And then we would re-relativize them and
>> adapt them to the current project when including them as history?
>
> Okay, I did that. Extremely rough patch follows.
Thanks! It's very close to what I was thinking of (modulo some cosmetics
and perf optimizations).
> Btw, the reason I'm interested in this shared project history is because
> our workflow involves creating many new projects (one per branch); so
> mostly each project has no history at all, and sharing history between
> projects is the only way to get any.
Now that you can have this additional capability as an option, do you
think you will be using it as well?
> But, it seems to me that this doesn't really help with having the
> current file be "future history". That's still useful when switching
> between similar projects. And all the logic of my other patch which
> does that, is still required with this patch.
Indeed, that's a good point. So I think we'll install your first patch
either way.
Before we do that, small (or not so small) question: do you think we
should test that the current buffer exists in the other project too? We
could do that with file-exists-p (but that's an extra round-trip over
Tramp), or by checking against the full list like in below.
Relatedly, with the cross-project history, we should ask the same
question: will we check that the "transplanted" history entries
correspond to existing files in the other project (and filter out those
that don't).
WDYT?
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index d8b12c9c880..a32bc2dd8d3 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1116,7 +1116,10 @@ project-find-file-in
(completion-ignore-case read-file-name-completion-ignore-case)
(file (funcall project-read-file-name-function
"Find file" all-files nil 'file-name-history
- suggested-filename)))
+ (if (file-name-absolute-p suggested-filename)
+ (and (member suggested-filename all-files)
+ suggested-filename)
+ suggested-filename))))
(if (string= file "")
(user-error "You didn't specify the file")
(find-file file))))
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.
Received: (at 63829) by debbugs.gnu.org; 14 Aug 2023 22:47:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 14 18:47:22 2023
Received: from localhost ([127.0.0.1]:34576 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qVgLJ-0005Sd-GK
for submit <at> debbugs.gnu.org; Mon, 14 Aug 2023 18:47:22 -0400
Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:16352)
by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from
<bounces+21787432-9ab0-63829=debbugs.gnu.org@HIDDEN>)
id 1qVgLG-0005SO-QQ
for 63829 <at> debbugs.gnu.org; Mon, 14 Aug 2023 18:47:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com;
h=from:subject:in-reply-to:references:mime-version:to:cc:content-type:
content-transfer-encoding:cc:content-type:from:subject:to;
s=s1; bh=MOrtePnEZtD4TfJ++8R09Hkjf/k36FEzJ9EeRgL8dWc=;
b=K3Bsrp6Ul7v3+2LJzgg8hI6DuIhJ91T/GnnAtXEdLUtEK0eUH1EB0GTMMn8pWTzQlQg1
IysMudgAZrMrKSRUkUu8iUvmBGsqKBvMNPM++ysG/o9YvrdkXp81XYOKnRKjf+lnXqRp74
gLQZQUdIHmqmgKXpFZM/iSlGxSTm6fZ1N8mcKWKlnt4XOE80QcqcJxQeA/7sKaQSYcdaDv
TYShWcGQGTQpc9gUAu2TXa84cKNTCZJG75huHLe8L0L2QCYu9KJeeYjzz5mz6JGQkU0a8V
nBprYxt3+9/KS1leM9Q3vfEnHP1v4I3o6JGnU3SMId3zuJR9dfR35TQJWjotIeKw==
Received: by filterdrecv-77869f68cc-gch4b with SMTP id
filterdrecv-77869f68cc-gch4b-1-64DAAEF0-15
2023-08-14 22:47:12.861442738 +0000 UTC m=+8291472.021926090
Received: from earth.catern.com (unknown) by geopod-ismtpd-13 (SG) with ESMTP
id ubcR7YYMRlG3meaG0IfCCQ Mon, 14 Aug 2023 22:47:12.779 +0000 (UTC)
X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost;
envelope-from=sbaugh@HIDDEN; receiver=janestreet.com
Received: from localhost (localhost [IPv6:::1])
by earth.catern.com (Postfix) with ESMTPSA id EDB5060080;
Mon, 14 Aug 2023 18:47:11 -0400 (EDT)
From: sbaugh@HIDDEN
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
with common-parent-directory
In-Reply-To: <ier350lqt77.fsf@HIDDEN> (Spencer Baugh's message of
"Mon, 14 Aug 2023 16:12:28 -0400")
References: <ierpm6ezude.fsf@HIDDEN>
<16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN>
<ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN>
<3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN>
<iersfb48u0g.fsf@HIDDEN>
<d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN>
<ier350lqt77.fsf@HIDDEN>
Date: Mon, 14 Aug 2023 22:47:12 +0000 (UTC)
Message-ID: <87a5uti6mo.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJYVy14zYI25XyfifNLZo?=
=?us-ascii?Q?zEb4TdW2tr+r64ip47F+ZM5OSbNy8pzvINtE0+0?=
=?us-ascii?Q?hOSA20EyAYWcLHlfEQ9VgTS3jy8BFCR7pE7yfB+?=
=?us-ascii?Q?Iv212HCTzPYyq+JGnikL+P9i5=2F5XhKEKwyQneoc?=
=?us-ascii?Q?rUWj4eXsljlV4Jy3qJj=2FaqJBoC7KhApWv9g=3D=3D?=
To: Spencer Baugh <sbaugh@HIDDEN>
X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q==
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 63829
Cc: Dmitry Gutov <dmitry@HIDDEN>, 63829 <at> debbugs.gnu.org,
Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Spencer Baugh <sbaugh@HIDDEN> writes:
> Dmitry Gutov <dmitry@HIDDEN> writes:
>
>> Hi Spencer,
>>
>> Thanks for the ping.
>>
>> On 06/06/2023 18:55, Spencer Baugh wrote:
>>
>>>> But so far the patch over there is not complete yet, is it? I wouldn't
>>>> say it's a settled matter so far.
>>> Yes, I expect there are any number of alternative implementation
>>> strategies, I'm not at all tied to using
>>> project-current-directory-override. Happy to port to whatever approach
>>> we end up with.
>>
>> Notes:
>>
>> - We're still using project-current-directory-override, not migrated
>> to anything else yet.
>> - I've pushed my earlier patch which should fix the immediate bug as
>> reported.
>>
>> Let's talk about yours a little bit more. I'm a little wary of adding
>> a specialized feature this way (being able to visit the file
>> corresponding to the current one only), but that patch might be the
>> most optimal still.
>>
>>>>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127
>>>>> and then it was deemed to be not too general to handle, so I backed it out
>>>>> inhttps://debbugs.gnu.org/58447#160 with such conclusion:
>>>>> OTOH, `C-x p f M-p' in another project is not my primary
>>>>> workflow.
>>>>> But if someone wants to keep a plain history, this could be added
>>>>> later in master, e.g. by a new value of project-read-file-name-function
>>>>> and a function that is mostly a copy of project--read-file-cpd-relative.
>>>>> So maybe this could be implemented in master now?
>>>>
>>>> I think the design there was to use relative file names in history? Or
>>>> a different variable for project file name history (which would use
>>>> relative names only). I'm not ruling that out, but the patch proposed
>>>> here is a little more focused.
>>>>
>>>> OTOH, it only allows finding the "current" file in the other project,
>>>> but not other files that were previously visited too. Spencer, what do
>>>> you think about that capability? Do you also feel it is missing and
>>>> would like to look into it next? Then the current patch might be the
>>>> wrong direction.
>>> Hm, the main thing I want is to make it very easy to visit the
>>> current
>>> file in another project - I am frequently getting user requests for that
>>> feature. (Mainly because our workflow heavily uses a "git worktree"
>>> equivalent, where users have one project for each bug/branch they're
>>> working on, all with basically the same layout, so "visit the same file
>>> in a different project" is also "visit the same file in a different
>>> branch", which is often useful. (I actually might work on some code to
>>> help implement the same kind of workflow for Emacs development, one
>>> worktree per bug/branch))
>>
>> I suppose one other way to do that would be to create a dedicated
>> command just for that. But that's a little clunkier -- would require a
>> separate binding.
>>
>>> I'm not sure I understand the alternative - the idea would be to share
>>> project file name history between all projects? I guess that could be
>>> nice, although I don't personally use file name history that much, and
>>> AFAIK it wouldn't solve any concrete user problems, so I'm not really
>>> motivated to implement it.
>>
>> The alternative is a little more general, e.g. propertize every such
>> history entry with the value of the root, so that they can be
>> post-processed to adapt to any other root directory.
>>
>> This shouldn't take too much work, actually. But I don't know if that
>> is indeed a necessary feature. From the discussion
>> (https://debbugs.gnu.org/58447), I had been under impression that it
>> would be wanted, but it might be just "nice to have".
>
> I would be happy to do that. That sounds very cool actually.
>
> Can you elaborate on how exactly you imagine this happening? I guess,
> every time someone enters a filename with project-find-file or
> project-find-dir, we would include a propertized version of that
> filename in file-name-history? And then we would re-relativize them and
> adapt them to the current project when including them as history?
Okay, I did that. Extremely rough patch follows.
Btw, the reason I'm interested in this shared project history is because
our workflow involves creating many new projects (one per branch); so
mostly each project has no history at all, and sharing history between
projects is the only way to get any.
But, it seems to me that this doesn't really help with having the
current file be "future history". That's still useful when switching
between similar projects. And all the logic of my other patch which
does that, is still required with this patch.
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 78f9fb410c1..5752f26d229 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1028,6 +1028,12 @@ project-read-file-name-function
:group 'project
:version "27.1")
+(defun project--expand-file-name (filename project)
+ (when-let ((old-pr (get-text-property 0 'project filename)))
+ (expand-file-name
+ (file-relative-name filename (project-root old-pr))
+ (project-root project))))
+
(defun project--read-file-cpd-relative (prompt
all-files &optional predicate
hist mb-default)
@@ -1038,7 +1044,8 @@ project--read-file-cpd-relative
MB-DEFAULT is used as part of \"future history\", to be inserted
by the user at will."
- (let* ((common-parent-directory
+ (let* ((project (project-current t))
+ (common-parent-directory
(let ((common-prefix (try-completion "" all-files)))
(if (> (length common-prefix) 0)
(file-name-directory common-prefix))))
@@ -1060,6 +1067,7 @@ project--read-file-cpd-relative
((symbol-value hist)
(mapcan
(lambda (s)
+ (setq s (or (abbreviate-file-name (project--expand-file-name s project)) s))
(and (string-prefix-p abbr-cpd s)
(not (eq abbr-cpd-length (length s)))
(list (substring s abbr-cpd-length))))
@@ -1070,7 +1078,9 @@ project--read-file-cpd-relative
hist mb-default)))
(absname (expand-file-name relname common-parent-directory)))
(when (and hist history-add-new-input)
- (add-to-history hist (abbreviate-file-name absname)))
+ (add-to-history hist (propertize
+ (abbreviate-file-name absname)
+ 'project project)))
absname))
(defun project--read-file-absolute (prompt
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 14 Aug 2023 20:12:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 14 16:12:37 2023 Received: from localhost ([127.0.0.1]:34471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qVdvZ-0001YY-8t for submit <at> debbugs.gnu.org; Mon, 14 Aug 2023 16:12:37 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:33625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1qVdvX-0001YI-4W for 63829 <at> debbugs.gnu.org; Mon, 14 Aug 2023 16:12:36 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory In-Reply-To: <d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN> (Dmitry Gutov's message of "Sat, 12 Aug 2023 04:23:14 +0300") References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> <iersfb48u0g.fsf@HIDDEN> <d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN> Date: Mon, 14 Aug 2023 16:12:28 -0400 Message-ID: <ier350lqt77.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63829 Cc: Juri Linkov <juri@HIDDEN>, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> writes: > Hi Spencer, > > Thanks for the ping. > > On 06/06/2023 18:55, Spencer Baugh wrote: > >>> But so far the patch over there is not complete yet, is it? I wouldn't >>> say it's a settled matter so far. >> Yes, I expect there are any number of alternative implementation >> strategies, I'm not at all tied to using >> project-current-directory-override. Happy to port to whatever approach >> we end up with. > > Notes: > > - We're still using project-current-directory-override, not migrated > to anything else yet. > - I've pushed my earlier patch which should fix the immediate bug as > reported. > > Let's talk about yours a little bit more. I'm a little wary of adding > a specialized feature this way (being able to visit the file > corresponding to the current one only), but that patch might be the > most optimal still. > >>>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >>>> and then it was deemed to be not too general to handle, so I backed it out >>>> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >>>> OTOH, `C-x p f M-p' in another project is not my primary >>>> workflow. >>>> But if someone wants to keep a plain history, this could be added >>>> later in master, e.g. by a new value of project-read-file-name-function >>>> and a function that is mostly a copy of project--read-file-cpd-relative. >>>> So maybe this could be implemented in master now? >>> >>> I think the design there was to use relative file names in history? Or >>> a different variable for project file name history (which would use >>> relative names only). I'm not ruling that out, but the patch proposed >>> here is a little more focused. >>> >>> OTOH, it only allows finding the "current" file in the other project, >>> but not other files that were previously visited too. Spencer, what do >>> you think about that capability? Do you also feel it is missing and >>> would like to look into it next? Then the current patch might be the >>> wrong direction. >> Hm, the main thing I want is to make it very easy to visit the >> current >> file in another project - I am frequently getting user requests for that >> feature. (Mainly because our workflow heavily uses a "git worktree" >> equivalent, where users have one project for each bug/branch they're >> working on, all with basically the same layout, so "visit the same file >> in a different project" is also "visit the same file in a different >> branch", which is often useful. (I actually might work on some code to >> help implement the same kind of workflow for Emacs development, one >> worktree per bug/branch)) > > I suppose one other way to do that would be to create a dedicated > command just for that. But that's a little clunkier -- would require a > separate binding. > >> I'm not sure I understand the alternative - the idea would be to share >> project file name history between all projects? I guess that could be >> nice, although I don't personally use file name history that much, and >> AFAIK it wouldn't solve any concrete user problems, so I'm not really >> motivated to implement it. > > The alternative is a little more general, e.g. propertize every such > history entry with the value of the root, so that they can be > post-processed to adapt to any other root directory. > > This shouldn't take too much work, actually. But I don't know if that > is indeed a necessary feature. From the discussion > (https://debbugs.gnu.org/58447), I had been under impression that it > would be wanted, but it might be just "nice to have". I would be happy to do that. That sounds very cool actually. Can you elaborate on how exactly you imagine this happening? I guess, every time someone enters a filename with project-find-file or project-find-dir, we would include a propertized version of that filename in file-name-history? And then we would re-relativize them and adapt them to the current project when including them as history? And also, we'd always prepend the current file as "future history", propertized in this way? > Juri, are *you* okay with the functionality in Spencer's patch? No > need for further generality? > >> However, if we did share project file name history in that way, I'd want >> to still automatically prepend the "current file" as history. Even if >> we didn't navigate to the current file via project-find-file, I still >> want to make it very easy to visit the current file in another project. >> Just sharing project file name history doesn't provide that. > > Fair point.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 12 Aug 2023 01:23:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 11 21:23:29 2023 Received: from localhost ([127.0.0.1]:48304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qUdLl-0007nb-A5 for submit <at> debbugs.gnu.org; Fri, 11 Aug 2023 21:23:29 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:56089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qUdLh-0007nJ-Hq for 63829 <at> debbugs.gnu.org; Fri, 11 Aug 2023 21:23:28 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9D2A932003F4; Fri, 11 Aug 2023 21:23:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 11 Aug 2023 21:23:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691803398; x=1691889798; bh=ctXOz0Crg7LjzdSVfxe/CIrN9BMW0Bj0Jgu MQ9Z4Pts=; b=JlIzDObkn+wZrGSz6ZnxRWHsVJ483dSoRhEDoxFRhO/m3WRSOjg x7gWmL9M+uG8S2cFGSq6P9tMjcdMkU6qdgtmyBW7gJ+EH7H8ryRuvSuyNYEmmk9R Mi1nhQLE8UTVBf5O9Yq48NwEhAgN+u9E87ARKeLlAivO5nzYu55iFNjNl6RSQSFm ED9pp/rqL6STTDi3x8XZaH5aKvH9rpklcp9irRIpAQiLNXdEfmZLvHribJakmGSp dUwVyNlDoeUQmenFYSkepPU9paQ1ftHfRds9EtCLSjcZpod8qPCqeA8giQomiOkz 3cj7hoDutiSOOTHzvb4Hn0iAQwdyMbvCa0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691803398; x=1691889798; bh=ctXOz0Crg7LjzdSVfxe/CIrN9BMW0Bj0Jgu MQ9Z4Pts=; b=Z3iU2XLjvpW4YCr2cNkv2pdWtBc3g7ADPfDmLy8Tz9VS9Zaf0Ak xT9NJeFbBm67awRwU1VwAsxp8HjXlbBX2285AQYh65WtTaZQA6FXFk26pNgnX0k4 fvpLTXyNIdP3xDWdMv4nB9u476uzor+dkz/cnmS4rg4YHSO3Jv1bo39NHNe/1HvO HcuOvOcEkxqBGZkNjfd1R4mY72QS9dosGV0uSJWQLR+orx53SkH/+rrI+4vMwsXl y1DTXCrxz8xF+k8GzV5PaKM011mFPQ971mrdVoAKNs7SS8p4LNwTHDB7ORy2TCaR yl2K7sfl5sD3ttsYDgd55TzzP50PSrr6ZHw== X-ME-Sender: <xms:Bd_WZDEK4pcd6Fqx2W_ivQpFPziHWKZwXmzX5DtCO2y_S8abdUXqPA> <xme:Bd_WZAV5iOsxbxR0gezY2TCa2yHTol9cezprggux2l6TgcRyRNFp_AM4Iresu_KqA vooPhWY9_G7XUuSL1c> X-ME-Received: <xmr:Bd_WZFJd0sPJ43vIzeYnEos4hxMIpLjpJKXDFH1TSkqu5futhHd7cGQ4nVCi5ZA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleelgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedvvdej leenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:Bd_WZBHU5Mi_5pbUmTGyx5l6f-dc-SggqS95m-rPxZQujHtha4gk3g> <xmx:Bd_WZJVV5Zmz0N9aMr8ECgfwM-N0FQ2jGjv_VHlLTf_mLRnet3ogiQ> <xmx:Bd_WZMPqyy2I7TQ-rnHEKp0rwlTXoEQcRba6RPKWkn8ywzzgX8kWhA> <xmx:Bt_WZIfwAVZPatdOfybv1HStYryAQXpWo4MIVPd4HTZ_Gm7qmdkeLw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Aug 2023 21:23:16 -0400 (EDT) Message-ID: <d3f75983-1d7f-fbd1-dda0-83377165295f@HIDDEN> Date: Sat, 12 Aug 2023 04:23:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Content-Language: en-US To: Spencer Baugh <sbaugh@HIDDEN> References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> <iersfb48u0g.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <iersfb48u0g.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 63829 Cc: 63829 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.8 (-) Hi Spencer, Thanks for the ping. On 06/06/2023 18:55, Spencer Baugh wrote: >> But so far the patch over there is not complete yet, is it? I wouldn't >> say it's a settled matter so far. > > Yes, I expect there are any number of alternative implementation > strategies, I'm not at all tied to using > project-current-directory-override. Happy to port to whatever approach > we end up with. Notes: - We're still using project-current-directory-override, not migrated to anything else yet. - I've pushed my earlier patch which should fix the immediate bug as reported. Let's talk about yours a little bit more. I'm a little wary of adding a specialized feature this way (being able to visit the file corresponding to the current one only), but that patch might be the most optimal still. >>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >>> and then it was deemed to be not too general to handle, so I backed it out >>> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >>> OTOH, `C-x p f M-p' in another project is not my primary >>> workflow. >>> But if someone wants to keep a plain history, this could be added >>> later in master, e.g. by a new value of project-read-file-name-function >>> and a function that is mostly a copy of project--read-file-cpd-relative. >>> So maybe this could be implemented in master now? >> >> I think the design there was to use relative file names in history? Or >> a different variable for project file name history (which would use >> relative names only). I'm not ruling that out, but the patch proposed >> here is a little more focused. >> >> OTOH, it only allows finding the "current" file in the other project, >> but not other files that were previously visited too. Spencer, what do >> you think about that capability? Do you also feel it is missing and >> would like to look into it next? Then the current patch might be the >> wrong direction. > > Hm, the main thing I want is to make it very easy to visit the current > file in another project - I am frequently getting user requests for that > feature. (Mainly because our workflow heavily uses a "git worktree" > equivalent, where users have one project for each bug/branch they're > working on, all with basically the same layout, so "visit the same file > in a different project" is also "visit the same file in a different > branch", which is often useful. (I actually might work on some code to > help implement the same kind of workflow for Emacs development, one > worktree per bug/branch)) I suppose one other way to do that would be to create a dedicated command just for that. But that's a little clunkier -- would require a separate binding. > I'm not sure I understand the alternative - the idea would be to share > project file name history between all projects? I guess that could be > nice, although I don't personally use file name history that much, and > AFAIK it wouldn't solve any concrete user problems, so I'm not really > motivated to implement it. The alternative is a little more general, e.g. propertize every such history entry with the value of the root, so that they can be post-processed to adapt to any other root directory. This shouldn't take too much work, actually. But I don't know if that is indeed a necessary feature. From the discussion (https://debbugs.gnu.org/58447), I had been under impression that it would be wanted, but it might be just "nice to have". Juri, are *you* okay with the functionality in Spencer's patch? No need for further generality? > However, if we did share project file name history in that way, I'd want > to still automatically prepend the "current file" as history. Even if > we didn't navigate to the current file via project-find-file, I still > want to make it very easy to visit the current file in another project. > Just sharing project file name history doesn't provide that. Fair point.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 10 Aug 2023 12:02:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 10 08:02:45 2023 Received: from localhost ([127.0.0.1]:41594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qU4NJ-0007am-4B for submit <at> debbugs.gnu.org; Thu, 10 Aug 2023 08:02:45 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:49522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bounces+21787432-9ab0-63829=debbugs.gnu.org@HIDDEN>) id 1qU4NF-0007aV-Sz for 63829 <at> debbugs.gnu.org; Thu, 10 Aug 2023 08:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=biuNuXK98EppuooOTjC4QAiktPJ6Rj04bdu7Q/u6nJY=; b=0oNPEpuCFABlArfJd1wpRJBPUrcUYJylpnmWTRWgDKF0q0CmkqLPm60Ro7/bUjWlVWzO oBCrbkaD1c3ZsxofBzhSnjrHVi77tHh10lkZDJQ3GSklNw9W9gcbSRuycItJEVgLgrOsbv XwU1neGJenEfOB9qDQ7QVsWnc7eqvJ5tjKO71kwrlAWIlqZCVgsHAnqaXZZ1ErDAr0Ct6M Jny1ttNCQ595+aLDKLueykJNcegjqPTKpg5izGS0kvtCpAlsYG1jpXBulUv4GecPuIGvNa UJ6dcUQSFl4Qj6R5fZD5IWIsViNpZgODWHoxZ8fAuvB6jMWq8Ass195cT3LsQPeA== Received: by filterdrecv-d7bbbc8bf-n6gsj with SMTP id filterdrecv-d7bbbc8bf-n6gsj-1-64D4D1DC-1B 2023-08-10 12:02:36.138462616 +0000 UTC m=+7906969.641822867 Received: from earth.catern.com (unknown) by geopod-ismtpd-33 (SG) with ESMTP id jxMDA152R2uj_OCvQKY2lw Thu, 10 Aug 2023 12:02:36.050 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@HIDDEN; receiver=janestreet.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id BEF3860094; Thu, 10 Aug 2023 08:02:35 -0400 (EDT) From: sbaugh@HIDDEN Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory In-Reply-To: <iersfb48u0g.fsf@HIDDEN> (Spencer Baugh's message of "Tue, 06 Jun 2023 11:55:59 -0400") References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> <iersfb48u0g.fsf@HIDDEN> Date: Thu, 10 Aug 2023 12:02:36 +0000 (UTC) Message-ID: <87jzu3hzqc.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbKfaTKFrn6EdLgwHYvpab?= =?us-ascii?Q?jPrQRvxFkaHuyoqJr5pRG2C=2FMLA4tac2xWnmFwF?= =?us-ascii?Q?T+Bd8Qz+gu8peWcOsY5S4p2MGhrLuoMiGGyTKwN?= =?us-ascii?Q?adHRNd21R+KUnYCWCzqBHfT7VmLSSNiJht16PPz?= =?us-ascii?Q?5PgnU8K1odqLSq+nch1VmjQQdeiyWtqecLw=3D=3D?= To: Spencer Baugh <sbaugh@HIDDEN> X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii 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: Spencer Baugh <sbaugh@HIDDEN> writes: > Dmitry Gutov <dmitry@HIDDEN> writes: >> I think the design there was to use relative file names in history? Or >> a different variable for project fi [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <https://www.spamcop.net/bl.shtml?149.72.154.232>] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.154.232 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 63829 Cc: Dmitry Gutov <dmitry@HIDDEN>, Juri Linkov <juri@HIDDEN>, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.2 (/) Spencer Baugh <sbaugh@HIDDEN> writes: > Dmitry Gutov <dmitry@HIDDEN> writes: >> I think the design there was to use relative file names in history? Or >> a different variable for project file name history (which would use >> relative names only). I'm not ruling that out, but the patch proposed >> here is a little more focused. >> >> OTOH, it only allows finding the "current" file in the other project, >> but not other files that were previously visited too. Spencer, what do >> you think about that capability? Do you also feel it is missing and >> would like to look into it next? Then the current patch might be the >> wrong direction. > > Hm, the main thing I want is to make it very easy to visit the current > file in another project - I am frequently getting user requests for that > feature. (Mainly because our workflow heavily uses a "git worktree" > equivalent, where users have one project for each bug/branch they're > working on, all with basically the same layout, so "visit the same file > in a different project" is also "visit the same file in a different > branch", which is often useful. (I actually might work on some code to > help implement the same kind of workflow for Emacs development, one > worktree per bug/branch)) > > I'm not sure I understand the alternative - the idea would be to share > project file name history between all projects? I guess that could be > nice, although I don't personally use file name history that much, and > AFAIK it wouldn't solve any concrete user problems, so I'm not really > motivated to implement it. > > However, if we did share project file name history in that way, I'd want > to still automatically prepend the "current file" as history. Even if > we didn't navigate to the current file via project-find-file, I still > want to make it very easy to visit the current file in another project. > Just sharing project file name history doesn't provide that. Any thoughts about this and my earlier patch? I still am interested in providing this feature.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 6 Jun 2023 15:56:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 06 11:56:10 2023 Received: from localhost ([127.0.0.1]:52855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q6Z2X-0005FL-Q8 for submit <at> debbugs.gnu.org; Tue, 06 Jun 2023 11:56:10 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1q6Z2T-0005Em-5f for 63829 <at> debbugs.gnu.org; Tue, 06 Jun 2023 11:56:08 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory In-Reply-To: <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> (Dmitry Gutov's message of "Tue, 6 Jun 2023 04:40:04 +0300") References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> Date: Tue, 06 Jun 2023 11:55:59 -0400 Message-ID: <iersfb48u0g.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63829 Cc: 63829 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> writes: > On 04/06/2023 19:36, Juri Linkov wrote: >>> On top of your patch, I can implement the feature I mentioned with the >>> patch at the end. This causes the following nice behavior: >>> >>> 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el >>> 2. C-x p p ~/src/emacs/trunk >>> 3. f >>> 4. M-n and the minibuffer contains "lisp/progmodes/project.el" >>> 5. RET and we have now easily switched to the same file in another >>> project >>> >>> Does the implementation seem OK? >>> >>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >>> index ac7be8dcbb2..b1e01df5314 100644 >>> --- a/lisp/progmodes/project.el >>> +++ b/lisp/progmodes/project.el >>> @@ -1008,7 +1008,12 @@ project-find-file >>> (dirs (list root))) >>> (project-find-file-in >>> (or (thing-at-point 'filename) >>> - buffer-file-name) >>> + (and buffer-file-name >>> + (if-let (buffer-proj (and project-current-directory-override >>> + (project-current nil default-directory))) >> But we are going to remove project-current-directory-override in bug#63648 >> where default-directory will be changed to next-default-directory. > > I guess the proposed logic could be reimplemented without using > project-current-directory-override -- just based on the changed value > of default-directory. And using the parent directory of > buffer-file-name. > > But so far the patch over there is not complete yet, is it? I wouldn't > say it's a settled matter so far. Yes, I expect there are any number of alternative implementation strategies, I'm not at all tied to using project-current-directory-override. Happy to port to whatever approach we end up with. >> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >> and then it was deemed to be not too general to handle, so I backed it out >> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >> OTOH, `C-x p f M-p' in another project is not my primary >> workflow. >> But if someone wants to keep a plain history, this could be added >> later in master, e.g. by a new value of project-read-file-name-function >> and a function that is mostly a copy of project--read-file-cpd-relative. >> So maybe this could be implemented in master now? > > I think the design there was to use relative file names in history? Or > a different variable for project file name history (which would use > relative names only). I'm not ruling that out, but the patch proposed > here is a little more focused. > > OTOH, it only allows finding the "current" file in the other project, > but not other files that were previously visited too. Spencer, what do > you think about that capability? Do you also feel it is missing and > would like to look into it next? Then the current patch might be the > wrong direction. Hm, the main thing I want is to make it very easy to visit the current file in another project - I am frequently getting user requests for that feature. (Mainly because our workflow heavily uses a "git worktree" equivalent, where users have one project for each bug/branch they're working on, all with basically the same layout, so "visit the same file in a different project" is also "visit the same file in a different branch", which is often useful. (I actually might work on some code to help implement the same kind of workflow for Emacs development, one worktree per bug/branch)) I'm not sure I understand the alternative - the idea would be to share project file name history between all projects? I guess that could be nice, although I don't personally use file name history that much, and AFAIK it wouldn't solve any concrete user problems, so I'm not really motivated to implement it. However, if we did share project file name history in that way, I'd want to still automatically prepend the "current file" as history. Even if we didn't navigate to the current file via project-find-file, I still want to make it very easy to visit the current file in another project. Just sharing project file name history doesn't provide that.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 6 Jun 2023 01:40:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 05 21:40:15 2023 Received: from localhost ([127.0.0.1]:50603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q6LgF-0002Ii-5F for submit <at> debbugs.gnu.org; Mon, 05 Jun 2023 21:40:15 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1q6LgC-0002IU-8T for 63829 <at> debbugs.gnu.org; Mon, 05 Jun 2023 21:40:13 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1B1D75C008C; Mon, 5 Jun 2023 21:40:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 05 Jun 2023 21:40:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1686015607; x=1686102007; bh=EKRgbP0hBbn93X3PQa0zNAYztJKSUiKeXDL 5usnkt8I=; b=KsSriYJf7dsuUaG3fcewENybjDH4wHChceSOXG9yZyWlYHgHzvv W0gNaUnExLw10ZhznPPbg+DV3uv03je4WlmLkgkekuq/5sa0NxNjDlmqe12uauV3 bfvSGsvTl7MG29iR/Fz6XCO6xD93F/n/e25UOgakgR4Y8lyA7zxkkYP8IGxtY958 O4sVGjL+wR2RZ1PxGllHampVcZ/wTNlxmPtA4elnhfgK9qoJcAJvjHT0734uBREE ZSZ7O4chzTPn0TMir2iojris/WQJCyJUtYcaRI6bCPnapQXE2XfGrhqyc4l1MwkE NHIO3jb1edzcDG25/vzSAdLCEiEHUUEXKQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1686015607; x=1686102007; bh=EKRgbP0hBbn93X3PQa0zNAYztJKSUiKeXDL 5usnkt8I=; b=KtY6QG+r2yjV5WJkH2HMwlnGIVpdSXh5epwHFdY0k3ovHdgZrQd j7bJqn3aKS16a+gOG+DruBvgWKUtDRUmuW5bF7wJGd58R+FDwWAky2Mq6jrE+Ar+ InF9MpXVanBQAUP9xV5IXiCUMXEqQ9f3Y0pF35XMYm648D7ZUNKii+Y5n6PGlFma ngSh+l4oaAh4WQONGaohg+5VhL/YgCYLgmkQNTD/AT7W0n7MuI9w4VhhOrgpFSoc KF1v7hmnx/qxAuLQamKpf4FWwl/RzxCD/a7PGamDaHyhg8M+FC9X8Lyku99gcuIs t4wFhlu/csT2/gvITDDAscGBuiNL7DLFrnw== X-ME-Sender: <xms:do5-ZI9ElIJyqTDXzdM4adltQlJ8cP54UgmKiorxUQqNbaj1QVtGjA> <xme:do5-ZAvHg0yayXrFVP3ee8_T-MmxYwnTQZWbvya7F4GrJpM9ZCAh1sB22baqyNG5T XPWu4fMg2nxA9d-zck> X-ME-Received: <xmr:do5-ZOD5c_gyjVejSBiIltUKiNYU0s_xazyAx6XOLeBWzgpg7egPW41evWMwQKI> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedttddggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:do5-ZIcQRNsFl7bVF8CW7s2KlE9CI2JEmGoQkQcWlCe0aDXOuE5fcQ> <xmx:do5-ZNMXjA1SPJMbOgDhxNfs5hpOjVo4nRdxSzvI5CJveJWLh1Oqgg> <xmx:do5-ZClTeBPxE9IjGTo04Weobfs7eHUYSwoyaAzEWvOOiOBx2o5L9w> <xmx:d45-ZL0F5OGWVGltlTRtb56Zha3cRK-Z3CAcK1l3s9kJkbRnnSiddw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jun 2023 21:40:05 -0400 (EDT) Message-ID: <3e404df1-b3a9-f9e3-4270-f42df8b704c7@HIDDEN> Date: Tue, 6 Jun 2023 04:40:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Content-Language: en-US To: Juri Linkov <juri@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> <86h6rnw7gm.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86h6rnw7gm.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 63829 Cc: 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.8 (--) On 04/06/2023 19:36, Juri Linkov wrote: >> On top of your patch, I can implement the feature I mentioned with the >> patch at the end. This causes the following nice behavior: >> >> 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el >> 2. C-x p p ~/src/emacs/trunk >> 3. f >> 4. M-n and the minibuffer contains "lisp/progmodes/project.el" >> 5. RET and we have now easily switched to the same file in another >> project >> >> Does the implementation seem OK? >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index ac7be8dcbb2..b1e01df5314 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1008,7 +1008,12 @@ project-find-file >> (dirs (list root))) >> (project-find-file-in >> (or (thing-at-point 'filename) >> - buffer-file-name) >> + (and buffer-file-name >> + (if-let (buffer-proj (and project-current-directory-override >> + (project-current nil default-directory))) > But we are going to remove project-current-directory-override in bug#63648 > where default-directory will be changed to next-default-directory. I guess the proposed logic could be reimplemented without using project-current-directory-override -- just based on the changed value of default-directory. And using the parent directory of buffer-file-name. But so far the patch over there is not complete yet, is it? I wouldn't say it's a settled matter so far. > BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 > and then it was deemed to be not too general to handle, so I backed it out > inhttps://debbugs.gnu.org/58447#160 with such conclusion: > > OTOH, `C-x p f M-p' in another project is not my primary workflow. > But if someone wants to keep a plain history, this could be added > later in master, e.g. by a new value of project-read-file-name-function > and a function that is mostly a copy of project--read-file-cpd-relative. > > So maybe this could be implemented in master now? I think the design there was to use relative file names in history? Or a different variable for project file name history (which would use relative names only). I'm not ruling that out, but the patch proposed here is a little more focused. OTOH, it only allows finding the "current" file in the other project, but not other files that were previously visited too. Spencer, what do you think about that capability? Do you also feel it is missing and would like to look into it next? Then the current patch might be the wrong direction.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 4 Jun 2023 17:01:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 04 13:01:43 2023 Received: from localhost ([127.0.0.1]:47047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q5r6t-0007vH-DP for submit <at> debbugs.gnu.org; Sun, 04 Jun 2023 13:01:43 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:42815) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1q5r6s-0007us-4j for 63829 <at> debbugs.gnu.org; Sun, 04 Jun 2023 13:01:42 -0400 X-GND-Sasl: juri@HIDDEN X-GND-Sasl: juri@HIDDEN X-GND-Sasl: juri@HIDDEN Received: by mail.gandi.net (Postfix) with ESMTPSA id F3E3F1C0003; Sun, 4 Jun 2023 17:01:34 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory In-Reply-To: <ierpm6cajyv.fsf@HIDDEN> (Spencer Baugh's message of "Sat, 03 Jun 2023 07:00:56 -0400") Organization: LINKOV.NET References: <ierpm6ezude.fsf@HIDDEN> <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> <ierpm6cajyv.fsf@HIDDEN> Date: Sun, 04 Jun 2023 19:36:25 +0300 Message-ID: <86h6rnw7gm.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 63829 Cc: Dmitry Gutov <dmitry@HIDDEN>, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) > On top of your patch, I can implement the feature I mentioned with the > patch at the end. This causes the following nice behavior: > > 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el > 2. C-x p p ~/src/emacs/trunk > 3. f > 4. M-n and the minibuffer contains "lisp/progmodes/project.el" > 5. RET and we have now easily switched to the same file in another > project > > Does the implementation seem OK? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac7be8dcbb2..b1e01df5314 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1008,7 +1008,12 @@ project-find-file > (dirs (list root))) > (project-find-file-in > (or (thing-at-point 'filename) > - buffer-file-name) > + (and buffer-file-name > + (if-let (buffer-proj (and project-current-directory-override > + (project-current nil default-directory))) But we are going to remove project-current-directory-override in bug#63648 where default-directory will be changed to next-default-directory. BTW, I asked about this before in https://debbugs.gnu.org/58447#127 and then it was deemed to be not too general to handle, so I backed it out in https://debbugs.gnu.org/58447#160 with such conclusion: OTOH, `C-x p f M-p' in another project is not my primary workflow. But if someone wants to keep a plain history, this could be added later in master, e.g. by a new value of project-read-file-name-function and a function that is mostly a copy of project--read-file-cpd-relative. So maybe this could be implemented in master now?
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 13:49:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 03 09:49:07 2023 Received: from localhost ([127.0.0.1]:41907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q5Rcw-000378-KW for submit <at> debbugs.gnu.org; Sat, 03 Jun 2023 09:49:07 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1q5Rct-00036W-PE for 63829 <at> debbugs.gnu.org; Sat, 03 Jun 2023 09:49:05 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 953FB5C018A; Sat, 3 Jun 2023 09:48:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 03 Jun 2023 09:48:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1685800138; x=1685886538; bh=MqbgvtuvYosDSwPcO7t3g2cpiLjuHFCz2+H EhRBO+5g=; b=CzTehn//FKfOIDVmy8KwyjVHgNqpOzV3iOS/6Rru10mUSiE56DM LfBlmoN5h2tynyt4SeLKz3i0di6ASrGPsHfTcGkBmSrDoLC0C/kb7SCJDOWLi1ha DU62K5FFqo3zqjVxj50IR0N6zt7V5C3cxfLILnnofceMotQ+47Pd5b662wk8QBia agZx0O8jmXpHWBnUpDRORJ0cHgNgoenx8U7oj7uPARDqxOzpCBSdwX6wEnjUc85o HTpRvGOGIrnGW6hu5+e/PTeZhgHGiWQJ5eHsA2caOC3yQZ9JeMCjHGj9tfL0GhQ5 s5c013k7MqyPc/deh+UJJ+n/foD/1lRNKgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1685800138; x=1685886538; bh=MqbgvtuvYosDSwPcO7t3g2cpiLjuHFCz2+H EhRBO+5g=; b=LPIdiXj7CFvFVm5gdDoUBbnSjU7qm5VJ5P9tNTgcbxjGd9LFu8C GSzxu7pmCvEq+sIzQgrA5iwO1wCBWnMCWO3Bl5JYZj3KNdyk8ESjbLAdu7FpZd2L y8/BJDpaFAzH0uE9sdY4XGdB/8LI3cHEropYk9Mq9CIYGwueTVZ85TbQCAmPkvdD aK4Rrdu6BJNssSK2llK7CPTCfFH2HdF9KuwsA/VF0H6pOvw+enDNrZQX3jxuCs56 0W4gXXrwBsEpp7OK6hoR76rBRmKb/KUOQLZu3iam4Ki3B5BZaO6ZIBCTz4cLvAJU P/hGYIG1S46HB1tuQ1OCKaWb0f33iqBSliQ== X-ME-Sender: <xms:ykR7ZFz9Covv4CaKF0O9Rn_9NbPj2Wg7ebFYog-rzqu0_HTEdZIDpA> <xme:ykR7ZFSkFLS7enQz2q8Z8hKs32Nelh3Frn2saN1a6gNRU-T8beECCBboxhUax7_zb v5IahTyHNwpZQikduc> X-ME-Received: <xmr:ykR7ZPXHPYXOBiuNVR6nGIj1O4JOtnytNg2kA8xH84EbMGmYVa9lAQ794F99_B8> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:ykR7ZHits025VMKLMJFe0g3WmpKQsQuWiw6hCB0xm0Dz-FHECgrzHQ> <xmx:ykR7ZHBwProE37VgTtcM9VxnEpqDaYuMixyp2mz8dqoQ4HiBozSnRQ> <xmx:ykR7ZAIcwa1DhAxsnnYpUJY6ROUE_-8QHExdnEwZa3CJ1pc2Sf1I6Q> <xmx:ykR7ZM7vlVJSSo0CGcN3Pt8AjnYsbA1ls1DiXA47puypKJnLYqHt-w> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 09:48:57 -0400 (EDT) Message-ID: <9406d283-967a-85c6-d8db-5b9c9912a46f@HIDDEN> Date: Sat, 3 Jun 2023 16:48:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <ierpm6ezude.fsf@HIDDEN> <83r0qubbtk.fsf@HIDDEN> <2790cb95-cfc8-40ee-2a89-d9effe2c2060@HIDDEN> <83o7lw90ev.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <83o7lw90ev.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 63829 Cc: sbaugh@HIDDEN, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.8 (--) On 03/06/2023 15:48, Eli Zaretskii wrote: >> Do you like the patch I posted? It could be considered somewhere in that >> direction. > > I don't know enough about the details to have opinion of any > importance. But if the change goes in the direction I thought we > should go, then that's good. > >> Should it go to emacs-29 or master? > > Unless this is a bad problem, I'd prefer that the change goes to > master. Maybe it's not too serious, given that it requires the user to invoke "future history" (not everybody knows of it), and for the project to have all files in one subdirectory. >>>> (As a separate point: I ran into this while adding a feature for >>>> switching between projects with similar directory structures. I want to >>>> include the relative path in the starting project in the "future >>>> history", so that when you have a file in projectA open, you can switch >>>> to the same file in projectB with C-x p p f M-n RET. For example, >>>> switching between the same file in multiple clones of Emacs. But sadly >>>> the future history doesn't work properly right now even in a single >>>> project) >>> >>> Once again, this should work by using the right value of >>> default-directory; having relative filenames in the history up front >>> is not TRT. Relative file names in Emacs are always interpreted >>> relatively to default-directory, so if you start using relative names >>> disregarding default-directory, you will eventually run into trouble, >>> as various file-related primitives will fail with ENOENT. >> >> The problem here is that is a different/new scenario where Spencer wants >> to have a file name from one project be applied to another project. It >> seems like using absolute names would rather go in the opposite direction. > > If some command wants to produce file names in a different directory, > then that command should do something like > > (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY) > > The code which produces the original FILENAME should still produce an > absolute file name (or record its directory in some other way); it > should not know/assume anything about potential uses of that file > name. Sounds like Spencer's last patch. It's not too great that we'll make project-find-file aware of project-current-directory-override, though.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 12:48:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 03 08:48:00 2023 Received: from localhost ([127.0.0.1]:41774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q5Qfn-0001Cn-Et for submit <at> debbugs.gnu.org; Sat, 03 Jun 2023 08:48:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1q5Qfj-0001Bt-DV for 63829 <at> debbugs.gnu.org; Sat, 03 Jun 2023 08:47:57 -0400 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 <eliz@HIDDEN>) id 1q5Qfd-0004wf-Pd; Sat, 03 Jun 2023 08:47:49 -0400 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=eGUg3CmI0Piy8MPLylfklrVuuI6l/6Rc1xGr/K1wGyI=; b=EWiIQNLNWS3o BP16rYqtWPRBa4rUCfPrK7S5LRyjbpz13uX6Qa+5AM3w9HgNNrVxbbqfDM4xWML4frik+SR3ALfJM y2QLuGp9A8/0v/3FD/vs/p2hHJJh8PlrVQw1GYnvf4B8h8oqoNPw0wQo5nJAee41M6M1+k0d7afrE wKBOvwoXoENkr0Yj7Az2bQqV6ZjeD6TySDKcDIQJtjbb2MnhnOReyQknVGwShPI5ScoNa0VLNJIVF u7UWTDXFiLnM78Cqt9jsFbJ9n+oUy+jGksiXauqTgaW89fkOlxtJJHJbkVZXEzb47IPgCfoZ0GoOq drrJmhnCqG24Zqm7E92o+g==; 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 <eliz@HIDDEN>) id 1q5Qfd-00043j-9N; Sat, 03 Jun 2023 08:47:49 -0400 Date: Sat, 03 Jun 2023 15:48:40 +0300 Message-Id: <83o7lw90ev.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <2790cb95-cfc8-40ee-2a89-d9effe2c2060@HIDDEN> (message from Dmitry Gutov on Sat, 3 Jun 2023 15:19:55 +0300) Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory References: <ierpm6ezude.fsf@HIDDEN> <83r0qubbtk.fsf@HIDDEN> <2790cb95-cfc8-40ee-2a89-d9effe2c2060@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63829 Cc: sbaugh@HIDDEN, 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 3 Jun 2023 15:19:55 +0300 > Cc: 63829 <at> debbugs.gnu.org > From: Dmitry Gutov <dmitry@HIDDEN> > > On 02/06/2023 09:47, Eli Zaretskii wrote: > >> From: Spencer Baugh <sbaugh@HIDDEN> > >> Date: Thu, 01 Jun 2023 18:32:29 -0400 > >> > >> 1. emacs -Q > >> 2. Open a project where project-files only returns files in a certain > >> subdirectory. For example, a git repo /repo where the only file is > >> "dir/file.txt". > >> 3. Open dir/file.txt > >> 4. C-x p f ;; project-find file > >> 5. Observe that the prompt is "Find file in /repo/dir: " which correctly > >> contains the common parent directory between all the paths returned by > >> project-files. > >> 6. M-n ;; next-history-element > >> 7. The minibuffer now contains "dir/file.txt". RET will fail to > >> open the file. > >> > >> Instead, the common parent directory should be stripped from the "future > >> history" element. > > > > From my POV, this is a clear sign of too many kludges which override > > the usual Emacs conventions of what is default-directory. Stripping > > the parent directory is IMO not the right solution; instead, the > > default-directory of the command should be set so that what you want > > happens automatically. If you go the way of patching up the code > > instead of fixing this fundamental problem, there will be no end to > > patching up. > > TBH, I'm not sure which particular change you were proposing. I was talking about the description of the problem, and what conclusion it caused me to draw. > Do you like the patch I posted? It could be considered somewhere in that > direction. I don't know enough about the details to have opinion of any importance. But if the change goes in the direction I thought we should go, then that's good. > Should it go to emacs-29 or master? Unless this is a bad problem, I'd prefer that the change goes to master. > >> (As a separate point: I ran into this while adding a feature for > >> switching between projects with similar directory structures. I want to > >> include the relative path in the starting project in the "future > >> history", so that when you have a file in projectA open, you can switch > >> to the same file in projectB with C-x p p f M-n RET. For example, > >> switching between the same file in multiple clones of Emacs. But sadly > >> the future history doesn't work properly right now even in a single > >> project) > > > > Once again, this should work by using the right value of > > default-directory; having relative filenames in the history up front > > is not TRT. Relative file names in Emacs are always interpreted > > relatively to default-directory, so if you start using relative names > > disregarding default-directory, you will eventually run into trouble, > > as various file-related primitives will fail with ENOENT. > > The problem here is that is a different/new scenario where Spencer wants > to have a file name from one project be applied to another project. It > seems like using absolute names would rather go in the opposite direction. If some command wants to produce file names in a different directory, then that command should do something like (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY) The code which produces the original FILENAME should still produce an absolute file name (or record its directory in some other way); it should not know/assume anything about potential uses of that file name. > > If the default-directory can be different for some elements of > > history, perhaps each element should have the default-directory > > metadata with it, e.g., as a property. Or maybe the history should > > hold absolute file names, and M-n etc. should convert it to relative > > as appropriate. > The latter is mostly what happens. I very much hope so, because anything else is going in the wrong direction.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 12:20:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 03 08:20:07 2023 Received: from localhost ([127.0.0.1]:41764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q5QEp-0000RR-8O for submit <at> debbugs.gnu.org; Sat, 03 Jun 2023 08:20:07 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1q5QEl-0000Qe-JY for 63829 <at> debbugs.gnu.org; Sat, 03 Jun 2023 08:20:05 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 811975C00A1; Sat, 3 Jun 2023 08:19:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 03 Jun 2023 08:19:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1685794798; x=1685881198; bh=Or7iHHOhYe1m8bLhGW9NfB1J3Vk8VNL+RzV UR9/d154=; b=YD864CT7Eor8mSkYBEzIiOHv2rxzqJGOwxSGdoAYC923q+rdkeg GqPeNSkrAjSH462JE03WFoU1u2tXgGjsAszhZHrGSGtW6/2c3PRU/yfsvZH4hC5j 92vrVI9Sv0IUGI32AmNfGaolExKFhlJga/xJhbFUx/lA4QNbnm0d9h57q88pBv4C teNjvIiOcurnPkFbM5ex0D+y14MzoiEqvesPcwpf0bZPfw1F5ScEJAj2Hjs2LvlY AQHohhlIfws8mGeDVw7itq+WOGBmzY5hZwmO+aTHF9D3t0fhmX+STTozqfJ0d9ch 11GU5AOb5/2KaQx4ty2tUqJWuekPhnNoFcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1685794798; x=1685881198; bh=Or7iHHOhYe1m8bLhGW9NfB1J3Vk8VNL+RzV UR9/d154=; b=FxIQrs1TLoM3vVwZejOpvscz8U2bN2e+30pEqXpiVbpqEGboi36 tll6nsvAENLuxyeFHB2liNsa5at82npoS+Qrz+xakXs+5h24WJT8/F8KbTJt53lM IvIfyLEo0PzA7NvJOrk/qDRiUaNjC4KSKcKDdiaUwXNnDjh4+1sW4Oj3A0n9VUVd rCvktN6jPy2h9g8/j8+HvlWmnGB7RMtPYvmOV4PCP5N2mhVz5V4+VSFvFl5UFKsy jq9CfxxZ3Dc2PkOYi1uoOZCqwW5ExLYzLTyl2DsP93pvb+xZpeGf3zpyhWrkXIYM XosoFzlJSXYUDO+70N3et5Z63PZcYUHTeEw== X-ME-Sender: <xms:7i97ZNoIvgV3EwmZJKa9UZIzOjZQl7HtFBS-vItQHdYNkB-XIb7-Zg> <xme:7i97ZPq8y6ouVFG14kPsynyl5SZVyy28ghB_144v1hDGPUuAsr6CFLxKHAGQ5VlGJ RWd3IoPyUFH7AzMMmk> X-ME-Received: <xmr:7i97ZKNqYL6soRIC7HwM0m7ZMdIJHjkWFfYSzJzPjXxbVpt-52POo2sJxwHm14g> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:7i97ZI5FA5yboONiofxRPSSMnLdwXpHp8la3QdRXaVGZ9Y_Zj4IyuA> <xmx:7i97ZM71Dd1kkYN5oK0Rr6wVLqJEZpuqs2TpNvGyemMhwMDr0_783Q> <xmx:7i97ZAhZl2j53osnnrokZlTeIaLNo2rheUcj_lD9chUyp8CqOapf9A> <xmx:7i97ZKQ0fH_2Qj7XyUE0NPeHgy-0mTy3BLWaJCNcpkCtB-231fO_LA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 08:19:56 -0400 (EDT) Message-ID: <2790cb95-cfc8-40ee-2a89-d9effe2c2060@HIDDEN> Date: Sat, 3 Jun 2023 15:19:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> References: <ierpm6ezude.fsf@HIDDEN> <83r0qubbtk.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <83r0qubbtk.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 63829 Cc: 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.8 (--) Hi Eli, On 02/06/2023 09:47, Eli Zaretskii wrote: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Date: Thu, 01 Jun 2023 18:32:29 -0400 >> >> 1. emacs -Q >> 2. Open a project where project-files only returns files in a certain >> subdirectory. For example, a git repo /repo where the only file is >> "dir/file.txt". >> 3. Open dir/file.txt >> 4. C-x p f ;; project-find file >> 5. Observe that the prompt is "Find file in /repo/dir: " which correctly >> contains the common parent directory between all the paths returned by >> project-files. >> 6. M-n ;; next-history-element >> 7. The minibuffer now contains "dir/file.txt". RET will fail to >> open the file. >> >> Instead, the common parent directory should be stripped from the "future >> history" element. > > From my POV, this is a clear sign of too many kludges which override > the usual Emacs conventions of what is default-directory. Stripping > the parent directory is IMO not the right solution; instead, the > default-directory of the command should be set so that what you want > happens automatically. If you go the way of patching up the code > instead of fixing this fundamental problem, there will be no end to > patching up. TBH, I'm not sure which particular change you were proposing. Do you like the patch I posted? It could be considered somewhere in that direction. Should it go to emacs-29 or master? >> (As a separate point: I ran into this while adding a feature for >> switching between projects with similar directory structures. I want to >> include the relative path in the starting project in the "future >> history", so that when you have a file in projectA open, you can switch >> to the same file in projectB with C-x p p f M-n RET. For example, >> switching between the same file in multiple clones of Emacs. But sadly >> the future history doesn't work properly right now even in a single >> project) > > Once again, this should work by using the right value of > default-directory; having relative filenames in the history up front > is not TRT. Relative file names in Emacs are always interpreted > relatively to default-directory, so if you start using relative names > disregarding default-directory, you will eventually run into trouble, > as various file-related primitives will fail with ENOENT. The problem here is that is a different/new scenario where Spencer wants to have a file name from one project be applied to another project. It seems like using absolute names would rather go in the opposite direction. > If the default-directory can be different for some elements of > history, perhaps each element should have the default-directory > metadata with it, e.g., as a property. Or maybe the history should > hold absolute file names, and M-n etc. should convert it to relative > as appropriate. The latter is mostly what happens.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.
Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 11:01:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 03 07:01:06 2023
Received: from localhost ([127.0.0.1]:41612 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1q5P0M-0001dH-Lk
for submit <at> debbugs.gnu.org; Sat, 03 Jun 2023 07:01:06 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43835)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <sbaugh@HIDDEN>) id 1q5P0J-0001cc-5F
for 63829 <at> debbugs.gnu.org; Sat, 03 Jun 2023 07:01:05 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
with common-parent-directory
In-Reply-To: <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN> (Dmitry Gutov's
message of "Sat, 3 Jun 2023 05:30:10 +0300")
References: <ierpm6ezude.fsf@HIDDEN>
<16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN>
Date: Sat, 03 Jun 2023 07:00:56 -0400
Message-ID: <ierpm6cajyv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 63829
Cc: 63829 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dmitry@HIDDEN> writes:
> Try the patch at the end, please. It seems to fix the scenario you
> presented. Does it help with the feature you mention below, too?
Yes, your patch works great and solves the cases I care about!
On top of your patch, I can implement the feature I mentioned with the
patch at the end. This causes the following nice behavior:
1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el
2. C-x p p ~/src/emacs/trunk
3. f
4. M-n and the minibuffer contains "lisp/progmodes/project.el"
5. RET and we have now easily switched to the same file in another
project
Does the implementation seem OK?
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac7be8dcbb2..b1e01df5314 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1008,7 +1008,12 @@ project-find-file
(dirs (list root)))
(project-find-file-in
(or (thing-at-point 'filename)
- buffer-file-name)
+ (and buffer-file-name
+ (if-let (buffer-proj (and project-current-directory-override
+ (project-current nil default-directory)))
+ (let ((buffer-root (project-root buffer-proj)))
+ (file-name-concat root (file-relative-name buffer-file-name buffer-root)))
+ buffer-file-name)))
dirs pr include-all)))
;;;###autoload
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.
Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 02:30:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 02 22:30:23 2023
Received: from localhost ([127.0.0.1]:41126 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1q5H26-0007zp-P4
for submit <at> debbugs.gnu.org; Fri, 02 Jun 2023 22:30:23 -0400
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:56201)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1q5H25-0007zW-14
for 63829 <at> debbugs.gnu.org; Fri, 02 Jun 2023 22:30:22 -0400
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.west.internal (Postfix) with ESMTP id 43954320092C;
Fri, 2 Jun 2023 22:30:13 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Fri, 02 Jun 2023 22:30:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:content-transfer-encoding:content-type:content-type:date:date
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to; s=fm3; t=
1685759412; x=1685845812; bh=1UI8QODFq6yx8JZww0XPvRNRm2P7XNIoz8y
C9sE7NCs=; b=c3Dm61L4jDWtnYIVS6vbIPC3Zl3+5UzkpAJNHSJmh5I/rJ4R+q+
kKaYlp/kpAbLRfnyN6dqsv2b06N2zjfygjyFHi5M8UKQ3Rs6umcNShhWDfoKcKln
PkLldsYi7lhgt0cj+lkY73Nf8nNDt7mfTjJw2ryO01sDUzUYa+OWQKHZd/4TTAhy
C+2AxyXjihdT4nEjzCyAxtvj0KI6gk+qZcbdaypd3Uo9Cl+JKQrWDJc3e4trNwNb
oTUgq7whX0lqMlc4IluN/Y6MbLGlL+kKj3+k13CScrkslBhyH/119+UayexiDvhc
kImEqOuFabhFNiA6PduJhFKWRHgRQiv4B7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1685759412; x=
1685845812; bh=1UI8QODFq6yx8JZww0XPvRNRm2P7XNIoz8yC9sE7NCs=; b=Q
d/RJX2q5N4aw5SWmqtJtvcmEoRbJVmDrdRZzI5Um2JQR40GVsLHCbt9PUAiS0im+
gvjuITiMqJz2f3wPUlhLFNm6Rk6lVXseOFJIJrPfk4ykzzwoivYDoM6FITLuJpI7
Epb+RMnywsEnGVYwAYvvJb4lZKIRP1uALIutAj7qiLh1K2FR/nlpG9vSIwXnoDpC
Wr8PXRDGZ9ZekIGRkh15F9YlRSsLfHcUF7CU0cja17a9ISIJc/6yBZhlI+38Hic8
UgCOhv5y4Pa3PfYAn97zlu6ll9Ccxf5dl6CoLPkS5X4AGn8iR2g44TL+s8jOhcQM
NbOHOr8A68KYqg6yfzUvg==
X-ME-Sender: <xms:tKV6ZCx4Tou5B5c28Pf7Ycll2-mGlYxIzLeCeqZqzi_Fmow-4I-1aw>
<xme:tKV6ZOTO5gjci1uMdUydHPs1tyIpjN0mLbuxqLQRBb2Gj4DsyoFNf18_o2ev1_cLN
zl9Jwjn6b2iRG-9RzI>
X-ME-Received: <xmr:tKV6ZEVHt5FBzeilQwCmJWzV3vaRsFovZsyij5rvGiOB0Nxr01_BAg_7jv5mV5o>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelgedgiedtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu
udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:tKV6ZIjCkIP0fXvl6E_Rz6A7TOriix1nOQNX8XXsnjj4TdMqGhE37A>
<xmx:tKV6ZEDIDJWVMvA5tMa3AOolWsq3aKoAfRx9Qs0d-kD-YuUiZNacyw>
<xmx:tKV6ZJJfQY4OPn90gfs2hoV6SdPV29xOSpI6tk4EXLEDCksqn6yoyA>
<xmx:tKV6ZPonKu6_1CEsohPBIaKfFtWyEdIGFG6G3YdBeGm-AKs4LuxGFw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
2 Jun 2023 22:30:11 -0400 (EDT)
Message-ID: <16b64d95-35e9-ef94-2c54-17b670111f0f@HIDDEN>
Date: Sat, 3 Jun 2023 05:30:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
with common-parent-directory
Content-Language: en-US
To: Spencer Baugh <sbaugh@HIDDEN>, 63829 <at> debbugs.gnu.org
References: <ierpm6ezude.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <ierpm6ezude.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: 63829
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)
Hi!
On 02/06/2023 01:32, Spencer Baugh wrote:
>
> 1. emacs -Q
> 2. Open a project where project-files only returns files in a certain
> subdirectory. For example, a git repo /repo where the only file is
> "dir/file.txt".
> 3. Open dir/file.txt
> 4. C-x p f ;; project-find file
> 5. Observe that the prompt is "Find file in /repo/dir: " which correctly
> contains the common parent directory between all the paths returned by
> project-files.
> 6. M-n ;; next-history-element
> 7. The minibuffer now contains "dir/file.txt". RET will fail to
> open the file.
Note that if you continue pressing 'M-n', you will see the corresponding
proper relative file names. The first one comes from the value
constructed in project-find-file. Which indeed looks problematic, since
we remove context in there by creating a relative name.
> Instead, the common parent directory should be stripped from the "future
> history" element.
Try the patch at the end, please. It seems to fix the scenario you
presented. Does it help with the feature you mention below, too?
It doesn't handle the case when (thing-at-point 'filename) returns a
relative file name that includes a directory name, relative to the
project root (where common-parent-directory differs), but that one seems
even more ambiguous.
> (As a separate point: I ran into this while adding a feature for
> switching between projects with similar directory structures. I want to
> include the relative path in the starting project in the "future
> history", so that when you have a file in projectA open, you can switch
> to the same file in projectB with C-x p p f M-n RET. For example,
> switching between the same file in multiple clones of Emacs. But sadly
> the future history doesn't work properly right now even in a single
> project)
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 7c51778d5d4..184f2316074 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1008,7 +1008,7 @@ project-find-file
(dirs (list root)))
(project-find-file-in
(or (thing-at-point 'filename)
- (and buffer-file-name (file-relative-name buffer-file-name root)))
+ buffer-file-name)
dirs pr include-all)))
;;;###autoload
@@ -1062,6 +1062,10 @@ project--read-file-cpd-relative
(delete common-parent-directory all-files))
t))
(substrings (mapcar (lambda (s) (substring s cpd-length))
all-files))
+ (mb-default (if (and common-parent-directory
+ (file-name-absolute-p mb-default))
+ (file-relative-name mb-default
common-parent-directory)
+ mb-default))
(_ (when included-cpd
(setq substrings (cons "./" substrings))))
(new-collection (project--file-completion-table substrings))
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at 63829) by debbugs.gnu.org; 2 Jun 2023 06:46:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 02 02:46:33 2023 Received: from localhost ([127.0.0.1]:38991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q4yYS-0007XS-Pt for submit <at> debbugs.gnu.org; Fri, 02 Jun 2023 02:46:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1q4yYN-0007X8-8W for 63829 <at> debbugs.gnu.org; Fri, 02 Jun 2023 02:46:30 -0400 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 <eliz@HIDDEN>) id 1q4yYH-0006bU-BO; Fri, 02 Jun 2023 02:46:21 -0400 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=OMW9MV1r1EpROuLO5G1XkvnBRnCVVNj+4w5AYJJ+kt4=; b=S1upZbpDvXsl utR1AFFK/FEKLbdua/iy/DjSK2NcWV9TzQUMQZuk+Rxa/8HGD6E+PbiSoV/PSBpcaAHNYR234cl+x 0es/1kPggro809I1jtCvAldOXLbTBGgExwN9II1ay8rCa/2vX+6SBbJRKZgU2NqtXiCR0RJg4qW/7 Yl8oNqfcFI6ttQJuaCAzI7t3XXJVdggHKc3DZS5d4g2pHI5IXx9OK7VxpZJj69dkiuN25owkg4yDX YII8Z2ipfw0t+x9uxUinf2wNSvXb8L75qQZ6MkaPJ6zk1BDT1TCwY1Cqsy6WJNUMOgMfzQdeD5FsO exsNf97sEapv/1YNrNY/zA==; 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 <eliz@HIDDEN>) id 1q4yYB-0007mp-9t; Fri, 02 Jun 2023 02:46:16 -0400 Date: Fri, 02 Jun 2023 09:47:03 +0300 Message-Id: <83r0qubbtk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierpm6ezude.fsf@HIDDEN> (message from Spencer Baugh on Thu, 01 Jun 2023 18:32:29 -0400) Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory References: <ierpm6ezude.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63829 Cc: 63829 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Date: Thu, 01 Jun 2023 18:32:29 -0400 > > 1. emacs -Q > 2. Open a project where project-files only returns files in a certain > subdirectory. For example, a git repo /repo where the only file is > "dir/file.txt". > 3. Open dir/file.txt > 4. C-x p f ;; project-find file > 5. Observe that the prompt is "Find file in /repo/dir: " which correctly > contains the common parent directory between all the paths returned by > project-files. > 6. M-n ;; next-history-element > 7. The minibuffer now contains "dir/file.txt". RET will fail to > open the file. > > Instead, the common parent directory should be stripped from the "future > history" element. From my POV, this is a clear sign of too many kludges which override the usual Emacs conventions of what is default-directory. Stripping the parent directory is IMO not the right solution; instead, the default-directory of the command should be set so that what you want happens automatically. If you go the way of patching up the code instead of fixing this fundamental problem, there will be no end to patching up. > (As a separate point: I ran into this while adding a feature for > switching between projects with similar directory structures. I want to > include the relative path in the starting project in the "future > history", so that when you have a file in projectA open, you can switch > to the same file in projectB with C-x p p f M-n RET. For example, > switching between the same file in multiple clones of Emacs. But sadly > the future history doesn't work properly right now even in a single > project) Once again, this should work by using the right value of default-directory; having relative filenames in the history up front is not TRT. Relative file names in Emacs are always interpreted relatively to default-directory, so if you start using relative names disregarding default-directory, you will eventually run into trouble, as various file-related primitives will fail with ENOENT. If the default-directory can be different for some elements of history, perhaps each element should have the default-directory metadata with it, e.g., as a property. Or maybe the history should hold absolute file names, and M-n etc. should convert it to relative as appropriate. Or something. But just treating relative file names as strings unrelated to the (implied) default-directory is simply WRONG in Emacs.
bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 1 Jun 2023 22:32:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 01 18:32:44 2023 Received: from localhost ([127.0.0.1]:38648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1q4qqa-00063a-5c for submit <at> debbugs.gnu.org; Thu, 01 Jun 2023 18:32:44 -0400 Received: from lists.gnu.org ([209.51.188.17]:58496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1q4qqU-00063M-Sq for submit <at> debbugs.gnu.org; Thu, 01 Jun 2023 18:32:42 -0400 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 <sbaugh@HIDDEN>) id 1q4qqP-0006yY-Hs for bug-gnu-emacs@HIDDEN; Thu, 01 Jun 2023 18:32:33 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>) id 1q4qqN-00067S-La for bug-gnu-emacs@HIDDEN; Thu, 01 Jun 2023 18:32:33 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 29.0.90; project-find-file's future history breaks with common-parent-directory Date: Thu, 01 Jun 2023 18:32:29 -0400 Message-ID: <ierpm6ezude.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) 1. emacs -Q 2. Open a project where project-files only returns files in a certain subdirectory. For example, a git repo /repo where the only file is "dir/file.txt". 3. Open dir/file.txt 4. C-x p f ;; project-find file 5. Observe that the prompt is "Find file in /repo/dir: " which correctly contains the common parent directory between all the paths returned by project-files. 6. M-n ;; next-history-element 7. The minibuffer now contains "dir/file.txt". RET will fail to open the file. Instead, the common parent directory should be stripped from the "future history" element. (As a separate point: I ran into this while adding a feature for switching between projects with similar directory structures. I want to include the relative path in the starting project in the "future history", so that when you have a file in projectA open, you can switch to the same file in projectB with C-x p p f M-n RET. For example, switching between the same file in multiple clones of Emacs. But sadly the future history doesn't work properly right now even in a single project) In GNU Emacs 29.0.90 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-05-17 built on igm-qws-u22796a Repository revision: 4d08492296c2a6d2910f2b740c2d2508275458fc Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: CentOS Linux 7 (Core) Configured using: 'configure --with-x-toolkit=lucid --with-gif=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix
Spencer Baugh <sbaugh@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#63829; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.