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

[Dmitry Gutov <dgutov@yandex.ru>]

On 26.12.2018 22:13, Stefan Monnier wrote:

>> That sounds like a fair concern, never thought about it. Do we want to have
>> both as generic functions, though? People will have to take care to keep
>> them in sync.
> 
> 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.

> We could define it to return a *sequence*, so it can either return > a list, or a stream, or an array, ..

OK, so we can turn it into a completion table simply by calling (seq-map 
#'identity files). Though there might be a better choice.

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.

And I'm thinking about this because there can be faster ways to list all 
files in the project than 'find' (e.g. 'git ls-files'). But 
xref-collect-matches should know nothing about 'git ls-files'.

And by streams you mean stream.el in ELPA, right? It mentions "IO 
streams" but has no examples of that. Guess it's still something to R&D.

> 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 only I'm not wedded to those names, but of those two commands the
> one that I use is project-query-replace.

This one also needs a docstring update (note to self or whoever).

>> Should we move both commands to the multifile package and name them, for
>> instance, multifile-project-find-regexp (or multifile-project-search) and
>> multifile-project-query-replace-regexp?
> 
> No opinion on that either.

OK, so unless somebody objects I'd like to move them to 
lisp/multifile.el and rename to multifile-project-find-regexp and 
multifile-project-query-replace-regexp.

>> Originally we thought that this kind of UI preference would be enacted using
>> xref-show-xrefs-function, but apparently that's not so easy to do.
> 
> I don't know what such an approach would look like.

Hmm, maybe it's not easily compatible with multifile, since this 
function is passed a list of hits already. Not a list of files.