[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
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.
- Re: project--completing-read-strict breaks ada-mode project completion table, (continued)
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/16
- Re: project--completing-read-strict breaks ada-mode project completion table, Stefan Monnier, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, John Yates, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, Stefan Monnier, 2019/01/17
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/18
- Re: project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/21
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/21
- Re: project--completing-read-strict breaks ada-mode project completion table, Stephen Leake, 2019/01/21
- Re: project--completing-read-strict breaks ada-mode project completion table, Dmitry Gutov, 2019/01/21
- Re: Making project-files the "canonical" generic,
Dmitry Gutov <=