|
From: | Dmitry Gutov |
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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |