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

[Dmitry Gutov]

On 27.12.2018 22:33, Juri Linkov wrote:

> 'git ls-files' seems very fast, and moreover it outputs only relative
> paths, not absolute.   On TAB completion with too long absolute paths
> the list of completions is quite unreadable.

That's a question of presentation, not data. And Stefan gave some 
pertinent suggestions in this thread.

Actually, if we didn't manage to have 'find' and 'git ls-files' output 
in the same format as each other, that would be a problem.

> Also is it possible to complete only on file names, not paths?

You can input a file name and press RET. If the name is unique, it will 
be completed fully. Isn't this the best possible scenario?

> > 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.
>
> I think they should mirror everything that makes sense to use in the
> multifile project: project-occur, project-grep, ...

"multifile project"

Stefan, I think Juri is (maybe unknowingly) hinting that the package's 
name is a bit unfortunate.

Every project is multifile (with very rare exceptions). It's not about that.

Or maybe I don't understand the suggestion.

I'm find with adding project-occur, whatever it might do. As for 
project-grep, we have project-find-regexp already. I think it's a better 
name.

> But I don't know to what existing command corresponds 'project-search'?
> I tried it on the Emacs source tree, but it failed with:

It's analogous to tags-search. Which is also an unfortunate name, IMO.

> Debugger entered--Lisp error: (compression-error "Opening input file" "error uncompressing 
> empty.zz.gz" "emacs/test/manual/etags/a-src/empty.zz.gz")

Does M-x project-find-regexp work in the same situation?