[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: Stefan Monnier
Subject: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el
Date: Thu, 27 Dec 2018 09:39:27 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> Not sure what you mean by "keep them in sync".
> Making sure to implement them in a compatible fashion.  My point is, it's
> probably better to leave just one if the other can (almost?) always be
> efficiently implemented in terms of it.

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

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

> And by streams you mean stream.el in ELPA, right?

Indeed.  Also known as lazy lists.

>> I think TRT is to take the above common-prefix-directory, add it to the
>> prompt, and remove it from each completion candidate: this will keep
>> substring completion working correctly (and working even better since
>> it won't uselessly find matches in the common prefix) and will also
>> clarify where the search takes place.
> Makes sense. Should work as long as '/' is in
> completion-pcm-word-delimiters.
> 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.


reply via email to

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