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

[Dmitry Gutov]

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?