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
On 23/08/2023 20:52, Juri Linkov wrote:
>> - The new option renamed to project-file-history-behavior with values t or
>> 'relativize. I thought about removing it, but after all, the change is
>> a bit exotic, so there's bound to be people who would want to disable
>> it. And the new name is also more extensible (extra behaviors I could
>> think of by now: 'relativize-when-exists or 'separate -- the latter could
>> mean to use separate history var other than file-name-history). No hurry
>> to implement any of those, though.
>> - project-or-external-find-file needs some special handling of the
>> relativization when external file names are chosen. Better solutions
>> welcome.
>> - Announcement in NEWS. :-)
>
> A typo in NEWS? 'relative' -> 'relativize'
Fixed, thanks.
> Also to reduce confusion for everyone who will look at it,
> better to rename the property to 'project-root' in:
>
> (propertize file 'project (project-root project))))
It seemed shorter and just as obvious when looking at the propertized
value. But if everyone thinks the change should be made, I don't mind.
> PS: The docstring mentions the limitation: "This only affects
> history entries added by earlier calls to `project-find-file'".
> There is no way to remove this limitation? Maybe some clever way
> to match every file name from the history against the list
> of all known project roots to find the root on the file name
> without property. This will also work when the file history
> is restored from the desktop file or by savehist.el.
That is doable, at the cost of having imprecise results (and some
odd-looking history entries from time to time). Is that cost low enough?
This bug report was last modified 1 year and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.