Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 27.12.2018 16:39, Stefan Monnier wrote:

> Right.  But I'm not sure which one should be the "canonical" one.
> Currently, the "canonical" one is the completion-table, and the
> files-list is defined based on it (while it's current definition only
> handles flat completion, that could be improved).

A flat list is a simpler structure, so we'd choose it by default. Less 
margin of error for implementors.

What are the main benefits of making the completion table overridable?

The potential of an external process doing the matching for us (and 
doing it faster on nonempty inputs)?

Returning completion table metadata?

>> I wonder if we could efficiently implement project-find-regexp on top of
>> a sequence like that, i.e. pipe to Grep with little overhead.
> 
> I can't see any reason why not.

I gave it a try, to reimplement project-find-regexp based on 
project-files is a straightforward way, pushed to branch 
scratch/project-files-pipe-grep.

Unfortunately, I couldn't exactly reach the performance of the find+grep 
version. Try:

(benchmark 10 '(project-find-regexp "xyz1"))
=> 5.60s
(benchmark 10 '(project-files-pipe-grep "xyz1"))
=> 6.31s or 6.10s, depending on the version

Any suggestions?

This is without streams, but I'm now more skeptical about their possible 
performance benefits in this scenario.

>> But this approach also needs the completion table to be flat, right?
> 
> Not necessarily: we could accumulate the prefix as long as it's the
> sole completion.
I think I see what you mean.