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

[Dmitry Gutov <dmitry@gutov.dev>]

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?