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: Mon, 14 Aug 2023 22:47:12 +0000 (UTC) Message-ID: <87a5uti6mo.fsf@catern.com> References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@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="18533"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Dmitry Gutov , 63829@debbugs.gnu.org, Juri Linkov To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 15 00:48:49 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 1qVgMi-0004Yh-Fx for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Aug 2023 00:48:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVgMS-000227-5B; Mon, 14 Aug 2023 18:48:32 -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 1qVgLz-0001zR-CV for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2023 18:48:03 -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 1qVgLx-00033f-PG for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2023 18:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qVgLx-0005Vp-Lr for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2023 18:48:01 -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: Mon, 14 Aug 2023 22:48:01 +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.169205324221000 (code B ref 63829); Mon, 14 Aug 2023 22:48:01 +0000 Original-Received: (at 63829) by debbugs.gnu.org; 14 Aug 2023 22:47:22 +0000 Original-Received: from localhost ([127.0.0.1]:34576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVgLJ-0005Sd-GK for submit@debbugs.gnu.org; Mon, 14 Aug 2023 18:47:22 -0400 Original-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 ) id 1qVgLG-0005SO-QQ for 63829@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== Original-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 Original-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@catern.com; receiver=janestreet.com Original-Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id EDB5060080; Mon, 14 Aug 2023 18:47:11 -0400 (EDT) In-Reply-To: (Spencer Baugh's message of "Mon, 14 Aug 2023 16:12:28 -0400") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbJYVy14zYI25XyfifNLZozEb4TdW2tr+r64ip47F+ZM5OSbNy8pzvINtE0+0hOSA20EyAYWcLHlfEQ9VgTS3jy8BFCR7pE7yfB+Iv212HCTzPYyq+JGnikL+P9i5/5XhKEKwyQneocrUWj4eXsljlV4Jy3qJj/aqJBoC7KhApWv9g== 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:267446 Archived-At: Spencer Baugh writes: > Dmitry Gutov 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