[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: Thu, 17 Jan 2019 06:04:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

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

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

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

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.

reply via email to

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