GNU bug report logs -
#70996
project-find-file defaults
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Fri, 17 May 2024 06:53:01 UTC
Severity: normal
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.