bug#47799: 28.0.50; Default `project-files' implementation doesn't work with quoted filenames

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 18. Apr. 2021 um 22:21 Uhr schrieb Dmitry Gutov <dgutov@yandex.ru>:

> >> Regarding your change, though, have you tried project-find-regexp in a
> >> "transient" project with a quoted root directory name?
> >>
> >> You've made project--files-in-directory quote the returned file names,
> >> but that list gets passed to xref-matches-in-files, which pipes them to
> >> find-grep in the end. I suppose xref-matches-in-files could use a step
> >> similar to (when remote-id ...) that is already there.
> >
> > Good point, I've pushed 6ebc6e12cf to fix. But xref.el should also be
> > fixed. Maybe I'll find some time to take a look at it.
>
> Yes, I think the fix needs to be in xref-matches-in-files, and it also
> needs to use file-name-quoted-p similarly to (file-remote-p
> default-directory, to avoid the mapping overhead when the list of file
> names is large.
>
> It's a realistic use case, and the impact is significant (e.g. 1s to
> list files, 2s to unquote them all), so please look into this soon. The
> fix in xref should be simple enough, I'd just like for someone to
> realistically test it before installing (I can send a patch, if you want).

Hah, I wasn't aware that quoting/unquoting is so slow.
Rather than making assumptions in xref-matches-in-files, maybe we
could work more with relative filenames. For example:
1. Add another project method "project-relative-files" that returns
filenames relative to the root. By default, this would call
project-files and make the filenames relative, but project
implementations can provide an optimized implementation.
2. Give xref-matches-in-files an optional root directory argument and
allow users to pass names relative to that root.
Then I think both project and xref could leave these relative
filenames alone. WDYT?