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: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 63829 <at> debbugs.gnu.org
Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory
Date: Sat, 3 Jun 2023 16:48:55 +0300

On 03/06/2023 15:48, Eli Zaretskii wrote:

>> Do you like the patch I posted? It could be considered somewhere in that
>> direction.
> 
> I don't know enough about the details to have opinion of any
> importance.  But if the change goes in the direction I thought we
> should go, then that's good.
> 
>> Should it go to emacs-29 or master?
> 
> Unless this is a bad problem, I'd prefer that the change goes to
> master.

Maybe it's not too serious, given that it requires the user to invoke 
"future history" (not everybody knows of it), and for the project to 
have all files in one subdirectory.

>>>> (As a separate point: I ran into this while adding a feature for
>>>> switching between projects with similar directory structures.  I want to
>>>> include the relative path in the starting project in the "future
>>>> history", so that when you have a file in projectA open, you can switch
>>>> to the same file in projectB with C-x p p f M-n RET.  For example,
>>>> switching between the same file in multiple clones of Emacs.  But sadly
>>>> the future history doesn't work properly right now even in a single
>>>> project)
>>>
>>> Once again, this should work by using the right value of
>>> default-directory; having relative filenames in the history up front
>>> is not TRT.  Relative file names in Emacs are always interpreted
>>> relatively to default-directory, so if you start using relative names
>>> disregarding default-directory, you will eventually run into trouble,
>>> as various file-related primitives will fail with ENOENT.
>>
>> The problem here is that is a different/new scenario where Spencer wants
>> to have a file name from one project be applied to another project. It
>> seems like using absolute names would rather go in the opposite direction.
> 
> If some command wants to produce file names in a different directory,
> then that command should do something like
> 
>     (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY)
> 
> The code which produces the original FILENAME should still produce an
> absolute file name (or record its directory in some other way); it
> should not know/assume anything about potential uses of that file
> name.

Sounds like Spencer's last patch. It's not too great that we'll make 
project-find-file aware of project-current-directory-override, though.

Previous Next

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