[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extract
From: |
Stefan Monnier |
Subject: |
Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el |
Date: |
Wed, 26 Dec 2018 15:13:41 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> +(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
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2018/12/25
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el,
Stefan Monnier <=
- 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
- Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Juri Linkov, 2018/12/27