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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Stefan,

I've only noticed this change recently, hence this late email.

On 22.09.2018 18:46, Stefan Monnier wrote:

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

> +  ;; FIXME: Maybe we should do the reverse: implement the default
> +  ;; `project-file-completion-table' on top of `project-files'.

Originally I figured that having the completion table be a basic part of 
the propocol gives some benefits:

* If there's a background process that filters files faster than Emacs, 
then it could actually provide faster file completion.
* Completion table is a "lazy" value, which can be handy.

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?

> +  (all-completions
> +   "" (project-file-completion-table
> +       project (or dirs (project-roots project)))))
> +
>   (defgroup project-vc nil
>     "Project implementation using the VC package."
>     :version "25.1"
> @@ -389,12 +401,17 @@ recognized."
>     ;; removing it when it has no matches.  Neither seems natural
>     ;; enough.  Removal is confusing; early expansion makes the prompt
>     ;; too long.
> -  (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.

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.

> +;;;###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? Maybe rename 
dired-do-search and dired-do-query-replace-regexp later as well.

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.

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?

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.