Re: Making project-files the "canonical" generic

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> Stephen, hi!

Hi.

> Since it was your initiative that eventually brought us
> project-find-file and project-file-completion-table, I'd like to ask:
>
> 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.

> 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.

I don't have a use-case for project-files, so I'd rather keep the status
quo.

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?

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"? Do we have any examples of that? find-file works
that way, but it's not a completion table.

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.

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.

It would make sense to make the DIRS arg optional in
project-file-completion-table, as it is in project-files.

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"?

--
-- Stephe