From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Date: Tue, 06 Jun 2023 11:55:59 -0400 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10701"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 63829@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 06 17:57:41 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 1q6Z40-0002WK-Rd for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Jun 2023 17:57:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q6Z3k-0003Az-Ub; Tue, 06 Jun 2023 11:57:24 -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 1q6Z3j-0003AF-AH for bug-gnu-emacs@gnu.org; Tue, 06 Jun 2023 11:57:23 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q6Z3O-0004Vk-Ij for bug-gnu-emacs@gnu.org; Tue, 06 Jun 2023 11:57:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q6Z3O-0005GT-0x for bug-gnu-emacs@gnu.org; Tue, 06 Jun 2023 11:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jun 2023 15:57: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.168606697020176 (code B ref 63829); Tue, 06 Jun 2023 15:57:01 +0000 Original-Received: (at 63829) by debbugs.gnu.org; 6 Jun 2023 15:56:10 +0000 Original-Received: from localhost ([127.0.0.1]:52855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Z2X-0005FL-Q8 for submit@debbugs.gnu.org; Tue, 06 Jun 2023 11:56:10 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Z2T-0005Em-5f for 63829@debbugs.gnu.org; Tue, 06 Jun 2023 11:56:08 -0400 In-Reply-To: <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> (Dmitry Gutov's message of "Tue, 6 Jun 2023 04:40:04 +0300") 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:263061 Archived-At: Dmitry Gutov 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.