Re: Making project-files the "canonical" generic

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

My ada-mode project stuff is not in a publicly accessible repo at the
moment. I guess it's time to fix that.

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

In my case, they don't; as I have said elsewhere, the Ada compiler tools
require flat paths, so the Ada project code doesn't use project-roots,
project-ignores. I have code that converts between the two, but calling
that for every use of project-files would be inefficient.

Providing a more flexible definition of project-path would fix that
problem.

> 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 could override project-files to return the correct list.

The completion table style I use does uniquification by appending enough
parent directories to make the file names unique (same as
uniquify-buffer-name-style post-forward-angle-brackets). I might be able
to make that work with the list returned by project-files, but currently
some of the work is done in the completion table code itself, as it is
traversing the directory path. When I wrote it, I tried but did not
succeed in keeping all the completion-style-dependent code out of the
table. Maybe things have changed.

The completion table is also lazy, in the sense that typing characters
in the completion buffer interrupts computation of the table, and it is
later resumed properly. I'm not sure "lazy" is the right term for this;
perhaps "interruptible"? I'm not clear if that mechanism would work thru
project-files.

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

? not in master as of 492ab1136860ef41c33a5e35a85fb721693f892b, fetched
today.

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

Yes, that makes sense. 

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

ok, so there are real examples that require project-files and
project-file-completion-table to be independent of each other.

And the user interface experience for completion tables is not fully
determined by completion-styles-alist, so my uniquifying completion
table above is not really an outlier.

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

See above.

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

But defining a non-flat table on top of project-files is not possible,
or at least very inefficient (you'd have to throw away all the nested
directory content).

So I don't think your goal is possible.

Low level facilities like project.el should enable _all_ possible use
cases, not rule out some in the name of simplicity.

I have no objection to the default implemention of
project-file-completion-table using project-files, but I don't think we
should eliminate the generic function.

Completion tables are a powerful feature of Emacs; we should not
restrict their use with projects.

-- 
-- Stephe