[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.
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.
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el,
Dmitry Gutov <=
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Stefan Monnier, 2018/12/26
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/26
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Stefan Monnier, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/27
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/31
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Eli Zaretskii, 2018/12/31
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/28
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/29
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Juri Linkov, 2018/12/29
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/30