GNU bug report logs - #63829
29.0.90; project-find-file's future history breaks with common-parent-directory

Previous Next

Full log

Message #107 received at 63829 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63829 <at> debbugs.gnu.org,
 sbaugh <at> catern.com
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
 with common-parent-directory
Date: Wed, 23 Aug 2023 03:37:23 +0300

On 21/08/2023 10:06, Juri Linkov wrote:
>>>> +(defcustom project-file-name-history-relativize nil
>>>> +  "If non-nil, paths in `file-name-history' are adjusted for the current project.
>>>> +
>>> Instead of, or in addition to 'project-file-name-history-relativize',
>>> another option may be needed to define whether to check the
>>> existence of the constructed file name.  This could help
>>> to filter out irrelevant file names constructed from
>>> different projects.
>>
>> It could indeed. But it could also prevent the user from easily creating
>> a new file with the name from a "sister" project.
> 
> It would be unfortunate to lose this useful feature.
> 
>> We've discussed this before in this thread, including the idea of some
>> predicate checking the projects for compatibility, etc. What behavior would
>> you actually choose yourself?
> 
> I guess introducing a notion of "sibling projects" is unavoiable
> to exclude such situations where relative file names from one project
> are proposed in an unrelated project:
> 
>    Find file in /project/root/: relative/filename/from/unrelated/project
> 
> Then one possibility is to add an option to define sibling projects.
> Like 'find-sibling-rules', but maybe simply to contain alists of
> sibling projects.  Or projects in 'project--list' could have
> a new property 'group' where a project belongs to.
> 
> Then sibling projects could share the common file history.
> 
> And a new command e.g. 'project-find-sibling-file' could
> jump to a sibling project file immediately in case of
> two sibling projects, or ask to select with completion
> for more projects.

That would require a new generic (project-sibling-projects) and a proper 
description of what a "sibling" project is supposed to be. And probably 
still not going to work for VC-aware backend OOTB (it'll require some 
backend specific hook for the users to define that logic).

Sounds a little complicated, so given that one can still reach almost 
the same functionality through history completion ('C-x p p ... RET f 
C-n RET'), maybe it's a bit of an overkill? I'm open to further 
arguments, though.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.