[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: Fri, 3 May 2019 03:48:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.

Attachment: project-find-file-read-fn.diff
Description: Text Data

reply via email to

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