From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.bugs Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Date: Wed, 16 Aug 2023 02:57:18 +0000 (UTC) Message-ID: <875y5fitiq.fsf@catern.com> References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4938"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , Juri Linkov , 63829@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 16 04:58:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qW6jp-00011W-CX for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Aug 2023 04:58:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qW6jW-0000Lg-DT; Tue, 15 Aug 2023 22:58:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qW6jV-0000LR-Kw for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 22:58:05 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qW6jS-0008H0-Ox for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 22:58:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qW6jS-0003wV-BN for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 22:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 02:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs Original-Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169215464915112 (code B ref 63829); Wed, 16 Aug 2023 02:58:02 +0000 Original-Received: (at 63829) by debbugs.gnu.org; 16 Aug 2023 02:57:29 +0000 Original-Received: from localhost ([127.0.0.1]:38513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW6iu-0003vf-P3 for submit@debbugs.gnu.org; Tue, 15 Aug 2023 22:57:29 -0400 Original-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 ) id 1qW6iq-0003vP-89 for 63829@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== Original-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 Original-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@catern.com; receiver=gutov.dev Original-Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 05C8F60155; Tue, 15 Aug 2023 22:57:17 -0400 (EDT) In-Reply-To: <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> (Dmitry Gutov's message of "Wed, 16 Aug 2023 04:49:58 +0300") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbKwY9OkpHA7ZJoTPPRPN7WFzyWwRgn8o5EcFoOV9dJtVvArnnou26AXIooRGLSszh820s1wxxqDgnNSG/hLgbUeSnehhQrQJsWuMva2PrMKIJnPtLhXt8AyYcuXc/oIOBOkXpph5Ni3ab0BhG3xmAU3TP4VTPtKUS1XJY8OWKppjw== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267545 Archived-At: Dmitry Gutov writes: > On 15/08/2023 01:47, sbaugh@catern.com 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))))