[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el
Date: Fri, 28 Dec 2018 05:45:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]