Re: Making project-files the "canonical" generic

[Dmitry Gutov <dgutov@yandex.ru>]

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.