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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> +(cl-defgeneric project-files (project &optional dirs)
>> +  "Return a list of files in directories DIRS in PROJECT.
>> +DIRS is a list of absolute directories; it should be some
>> +subset of the project roots and external roots."
>> +  ;; This default implementation only works if project-file-completion-table
>> +  ;; returns a "flat" completion table.
>
> 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".

> Not sure if item 1 is ever going to materialize, and it would only help in
> certain cases. But since file listing can be slow sometimes, should we
> consider having some other kind of return value, for performance?
> Say, a stream of some kind. It could be handy for multifile-based commands,
> since they only show one file at a time. Ideally, though, the stream should
> be easily composable with external tools like Grep.
>
> Ideas?

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

>> -  (let* ((new-prompt (if default
>> +  (let* (;; (initial-input
>> +         ;;  (let ((common-prefix (try-completion "" collection)))
>> +         ;;    (if (> (length common-prefix) 0)
>> +         ;;        (file-name-directory common-prefix))))
>
> Interesting suggestion if we only want to use this function in
> project-find-file. I see the same effect, though, if I just press TAB.

Having to type TAB makes the interface quite different from just
`find-file`.

> Or I can right away type a unique file name, press TAB and see it completed
> to the full file name. I wonder what other people think; I still haven't
> managed to get off Ido, personally.

Indeed, that's why that code is commented out: inserting the common
prefix is a bad idea for substring completion.

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.

>> +;;;###autoload
>> +(defun project-search (regexp)
>> +;;;###autoload
>> +(defun project-query-replace (from to)
>
> I'm not a fan of these names. I know they kind of mirror what we already
> have in the dired- namespace, but can't we do better?

If you have better ideas, by all means change them.

> I think it's going to be hard for a user to differentiate between
> project-find-regexp and project-search. And that they might also have
> a guess that the latter "searches" for a project among the opened ones.

Not only I'm not wedded to those names, but of those two commands the
one that I use is project-query-replace.  I only added the other one
"for completeness".

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

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


        Stefan