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

Previous Next

Full log

View this message in rfc822 format

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

On 20/08/2023 20:20, Juri Linkov wrote:
>> +(defcustom project-file-name-history-relativize nil
>> +  "If non-nil, paths in `file-name-history' are adjusted for the current project.
>> +
>> +When non-nil and in `project-find-file' or `project-find-dir',
>> +paths in `file-name-history' are adjusted to be relative to
>> +whatever the current project is, instead of the project which
>> +added those paths.  This only affects history entries added by
>> +earlier calls to `project-find-file' or `project-find-dir'.
>> +
>> +When `project-read-file-name-function' is
>> +`project--read-file-cpd-relative' (the default), this has the
>> +effect of sharing more history between projects.")
> 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.

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?

Previous Next

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