[Top][All Lists]

[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

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.

reply via email to

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