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

[Dmitry Gutov]

On 18.04.2021 23:06, Philipp Stephani wrote:

> > Regarding xref--find-ignores-arguments, it seems it would be economical
> > to do the quoting on the value passed to it. See f955df1.
>
> Since it's an internal function, this is mostly a matter of style. I
> prefer using Emacs filenames as function arguments as much as
> possible; it's the expected behavior for functions dealing with files,
> and Emacs doesn't have a strong enough type system to distinguish
> "Emacs filename" (which can be quoted or remote) from "filename for
> external programs" (which must be unquoted and local).

Matter of style, yes, but the way I fixed it requires one unquoting 
instead of two, which seems like a win.

Your point is also valid, of course.

> > 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).

> > A bit unfortunate for the users of large projects with quoted names, but
> > not sure what else we could do.
>
> Quoting is a purely lexical operation which should be reasonably fast
> even for a large list of files.
> For truly enormous projects, something like "list of all project
> files" is infeasible anyway.

File listing in projects backed by Git (at least) is quite optimized. 
For example, in a gecko-dev checkout:

(benchmark 1 '(project-files (project-current)))
=> 0.97s

(benchmark 1 '(mapcar #'file-name-unquote (project-files 
(project-current))))
=> 2.97s