bug#70996: project-find-file defaults

[Dmitry Gutov]

On 12/06/2024 16:52, Dmitry Gutov wrote:
> In case you agree with my concerns above (I'm happy to be convinced 
> otherwise), we could try to do something like
>
>    (completion-try-completion (thing-at-point 'filename)
>                               TABLE nil LEN)
>
> Unfortunately, we currently call thing-at-point earlier than 
> project-files is called. So some rethinking would have to be done (a 
> breaking change to project-find-file-in, apparently).

Actually, we could do the check inside project-find-file-in.

The tricky part is that project--file-completion-table (which adds the 
metadata property to the table, allowing for laxer matching due to the 
entry in completion-category-defaults) is called later - in 
project--read-file-cpd-relative and project--read-file-absolute.

And one reason for that is project--read-file-cpd-relative mapcar's the 
list through 'substring'. Which requires a list as input, and IIRC so 
the previous version first called 'all-completions'. Which wasn't free, 
especially with larger lists - but perhaps since the completion table is 
functional we could get away with returning a copy of the list when the 
prefix is empty...

Or maybe project--read-file-cpd-relative could use something like 
completion-table-subvert, which seems like it can avoid extra copying...

Alternatively, we'd change the calling convention even more and pass 
down a function that returns the list of "future history". And takes the 
completion table as argument, I suppose.