[Top][All Lists]

[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

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

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

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.

reply via email to

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