[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.
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/25
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Stefan Monnier, 2018/12/26
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/26
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Stefan Monnier, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el,
Dmitry Gutov <=
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/31
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Eli Zaretskii, 2018/12/31
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/28
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/29
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Juri Linkov, 2018/12/29
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/30
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Juri Linkov, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Juri Linkov, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/28