Re: Making project-files the "canonical" generic

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.01.2019 04:14, Stephen Leake wrote:

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

Why is that code so inefficient? Can't you get by with a limited list of 
ignores?

I don't see how it can work otherwise. project-files *cannot* describe 
different information than what project-roots combined with 
project-ignores do. Any API consumer should be allowed to use any of 
those function, not just project-files or project-file-completion-table.

Does the current implementation of project-find-regexp even work for you 
(it doesn't use the completion table)? And if so, how?

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

We have discussed this before. How would this work?

Say, we have project-find-regexp which uses project-roots and 
project-ignores to build its command. How would it work with a "more 
flexible definition"?

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

Yes. I think I'd rather you did that and stopped there (aside from the 
project-roots/project-ignores problem).

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

I have commented on this in another email, and I understand how you 
reached that solution. And I don't like it, sorry.

Doing all this using a completion style seems impossible, but you could 
implement the uniquification inside the (new) command, not inside the 
completion table. Then we'll have two commands for the same purpose, 
project-find-file and project-????-find-file. After, we could also try 
to combine them and make the behavior depend on the user preference.

The completion table seems like the wrong way to do it, though.

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

Err, I'm not sure how this works, but I think a project-files 
implementation could be "interruptible" as well.

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

Huh, you are right, sorry. It will be used for the default completion 
table, though. And I have plans for it to be used in project-find-regexp 
as well.

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

I don't follow. The fact that some completion tables are kind of tricky 
doesn't mean we need to allow them here. We should find some specific 
use to them for our particular purpose.

In any case, the comments that mention the "flat" bit are about how 
difficult those table make it for the commands that try to use them. 
Which is not an encouragement for having them supported.

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

Having UI depend on a backend is not really a great idea, IMO.

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

Could you elaborate on that? What have you tried, and how did it it fail 
to work?

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

All _feasible_ use cases. The said facility should itself remain usable 
and discourage buggy code.