[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making project-files the "canonical" generic
From: |
Dmitry Gutov |
Subject: |
Re: Making project-files the "canonical" generic |
Date: |
Sun, 13 Jan 2019 03:54:32 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 |
On 12.01.2019 21:53, Stephen Leake wrote:
Did you end up ever using it and/or integrating it with ada-mode,
Yes, but not yet in the ELPA version; I had been maintaining Emacs 24
compatibility there. That's now dropped, so I can use Emacs 25 functions
in future ada-mode releases.
Very good. If you don't mind sharing a link to the development repo,
that would be great.
If so, do you see any particular benefits in keeping
project-file-completion-table a generic function instead of
reimplementing it on top of the (somewhat) newly added project-files
generic?
It seems to me a completion table is more useful than a simple file
list; what is the use case for project-files? I've been vaguely
following the multifile.el discussion, but I don't remember seeing this.
What is your use for completion table? I mean, the ability to provide
your implementation. The default implementation should already work if
project-roots and project-ignores return the correct values.
The only big reason to do that that I know of, is to use a cached list
of files (or somehow fetch it quickly another way, without 'find'). But
project-files is just as suitable for that.
I don't have a use-case for project-files, so I'd rather keep the status
quo.
project-files is now used for project-find-file, and will be used for
project-find-regexp as well.
The thing about it is, project-files is easier to implement. So if we
don't have a particular reason for the backend author to provide their
own completion table entirely, we don't need to allow that.
I don't understand the comment about the default implementation of
project-files only working if the completion table is "flat". Typically
I use "flat" to mean "no recursive directories" when describing a path
(= list of directories). I don't know what "flat" means for a completion
table; what would a non-flat table be?
One where (all-completions "" table) would return not the full list of
files, but e.g. include some directories without their contents
directly. This can also work for completing-read if the table defines
the "completion boundaries" logic. Those completion tables are fairly
rare, naturally.
Hmm. Maybe a "non-flat" file completion table means "return files in a
directory only if the directory is completely in the string to be
completed"?
Pretty much, I guess.
Do we have any examples of that? find-file works
that way, but it's not a completion table.
ecomplete-completion-table is the one example that I found quickly, but
there are probably more.
Requiring project-file-completion-table to be implemented on top of
project-files prevents such non-flat completion tables, and also lazy
completion tables (the ada-mode completion table is flat and lazy).
Allowing user choice in completion tables is important.
Could you clarify about laziness?
Having the list of files be returned from a method makes it "lazy" in a
way already, since nobody has to fetch that list right away, they can
just pass the project instance around (and call the method when necessary).
It seems to me that the default implementation of project-files should
_not_ use project-file-completion-table, because it could easily be
incorrect (it should use "find" directly). It is up to the project
backend to ensure the two functions return consistent results.
If possible, I'd like to avoid this completion, and only have one of the
other. After all, defining project-files on top of non-flat completion
tables is also possible (I'm told), if not particularly easy.
It would make sense to make the DIRS arg optional in
project-file-completion-table, as it is in project-files.
*Shrug* I have no strong opinion on that.
Except that project-file-completion-table doesn't have to be a generic,
as far as I can see.
The docstring on project-files should state whether the file-names are
absolute, or relative to one of DIRS, or just the basename.
project-file-completion-table should state the same. Although perhaps
"filename completion table" implies "absolute file names"?
It probably does, but sure, we could use more expressive docstrings.
- Making project-files the "canonical" generic, was: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el, Dmitry Gutov, 2019/01/11
- Re: Making project-files the "canonical" generic, Stephen Leake, 2019/01/12
- Re: Making project-files the "canonical" generic,
Dmitry Gutov <=
- Re: Making project-files the "canonical" generic, Stephen Leake, 2019/01/14
- Re: Making project-files the "canonical" generic, Stefan Monnier, 2019/01/16
- Re: Making project-files the "canonical" generic, Dmitry Gutov, 2019/01/16
- Re: Making project-files the "canonical" generic, Stefan Monnier, 2019/01/17
- Re: Making project-files the "canonical" generic, Dmitry Gutov, 2019/01/17
- project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/16
- Re: project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/16
- Re: project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/18