On 19.04.2019 20:49, Stephen Leake wrote:
> 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).

I've seen similar results in my own optimization initiatives. Simple 
often beats being too clever.

> 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.

I think this is the key insight. And we don't really need complex 
completion styles or special completion tables (which wouldn't work 
across project implementations).

> 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).

Calling cdr is not hard, though. An extra wrapper can do that.

> 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.

Like I said before, we don't want project implementations to provide 
extra features like this by overriding project-file-completion-table. 
It's not customizable and thus not user-friendly.

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

All right. Let's try a different mechanism, though.

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

Let's not do UI inside completion tables. Or as little as possible, at 
least.

Here is my counter-proposal (attached). It both nicely factors out the 
common-parent-directory logic (which had no place in 
completing-read-strict anyway) and creates a customization point.

You can write a different project-find-file-read-fn that would render 
the file names differently. For instance, with the alist example, you 
could build it, call project--completing-read-strict on it, and cdr at 
the end. Or use a hash-table, etc. Let me know if you need any help with 
implementing that.