[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: Thu, 27 Dec 2018 03:49:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0

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

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.

reply via email to

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