Re: project--completing-read-strict breaks ada-mode project completion table

[Stephen Leake]

I've pushed a scratch branch scratch/project-uniquify-files with a
different approach to this issue.

I did some benchmarking, and realized that almost all of the time taken
by uniq-file-completion-table startup is spent scanning the disk for
file names, and filling the operating system disk cache. Doing all of
that first to get the file list, and then doing completion on the list,
is measureably slower than repeating the scan (using the cache) during
completion, but the difference is not enough to be noticeable (unless
the completion string eliminates most of the directories, which is not a
typical case for uniquify-files).

Since standard completion works with alists, one way to make the result
string different from the display string is to build an alist with the
display string as key. Then we just need to fetch the result string from
the alist; completing-read does not do that, unfortunately (I guess
because the cdr of the alist might not be a string, in general).

Also, in browsing around the completion sources, I found the
'quote/unquote' mechanism, which passes yet more actions to the
completion table function.

So I added 'alist to the completion table metadata, and a step in
completing-read-default to query the completion table with the 'alist
action if that metadata is present.

file-complete-root-relative and uniquify-files both use this mechanism;
they wrap an alist in a completion function that handles 'alist.

An alternate implementation would be to add a global variable or
argument to completing-read to do the alist step, but that would require
clients to know that the completion table is an alist.

project--completing-read-strict delegates the UI to the completion
table, with the default using file-complete-root-relative.

I have not updated ELPA to match this, but it should be
straight-forward.

-- 
-- Stephe