[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: project--completing-read-strict breaks ada-mode project completion t
From: |
Dmitry Gutov |
Subject: |
Re: project--completing-read-strict breaks ada-mode project completion table |
Date: |
Wed, 8 May 2019 01:35:46 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 07.05.2019 21:02, Stephen Leake wrote:
This works well for my use cases.
I'm glad.
It would be slightly more efficient if `project-find-file-read-fn' took
an 'all-files' arg instead of 'collection' (which is a completion-table
function); I have to do '(all-completions "" collection predicate)' to
get the files list to pass to uniq-file-uniquify.
I would like to, really.
The downside of that is other read-file-from-list functions might have
to duplicate 'project-file--completion-table' as well. Until we have
another example of this, we can't tell which design is better.
The real reason I went with this approach is so that the no-decorator
option would also work and use the same completion category. I.e.
(setq project-find-file-read-fn project--completing-read-strict)
would still work, except without hiding the common parent directory.
If project-find-file-read-fn is passed a flat list of files (which I
would personally prefer, for clarity), the "bare" option would still
have to be a wrapper that creates a completion table just for the sake
of passing the appropriate category to completing-read.
The difference in startup time is not noticeable, so I can live with it.
all-completions is pretty fast. I would prefer the cleanest possible
design here, though.
Paging Dr. Monnier. Stefan, what would you choose?
One nit; 'project-file--completion-table' would be better spelled
'project--file-completion-table'.
Similarly for 'project-find-file--read-cpd-relative'
Yes, thank you. It's a proof-of-concept patch for now, I'll make the
spelling edits later.