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

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.


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

+(defun project-search (regexp)

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

reply via email to

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