From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Fri, 19 Apr 2019 09:49:01 -0800 Message-ID: <86imv99982.fsf@stephe-leake.org> References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> <4e729d1e-bb31-455f-fd44-e99ae5a6b9fa@yandex.ru> <86zhs5r9lr.fsf_-_@stephe-leake.org> <08de4d90-d678-0524-9356-f9a3515bf0c4@yandex.ru> <86a7k2rabi.fsf@stephe-leake.org> <86sgxso27d.fsf@stephe-leake.org> <69076784-83cb-5cc7-be39-fea990b8535e@yandex.ru> <861s55n6wk.fsf@stephe-leake.org> <86lg2swg14.fsf@stephe-leake.org> <86wom5vlki.fsf@stephe-leake.org> <86sgwpuk2q.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="6435"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 19 20:02:53 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHXqe-0001Xt-Qn for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 20:02:52 +0200 Original-Received: from localhost ([127.0.0.1]:59664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHXqd-00011A-MR for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 14:02:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHXqP-00010t-S9 for emacs-devel@gnu.org; Fri, 19 Apr 2019 14:02:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHXqO-0005fP-Tm for emacs-devel@gnu.org; Fri, 19 Apr 2019 14:02:37 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:42316) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hHXqO-0005cx-N6 for emacs-devel@gnu.org; Fri, 19 Apr 2019 14:02:36 -0400 Original-Received: from CMGW (unknown [10.9.0.13]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 15D4B1AC644 for ; Fri, 19 Apr 2019 11:49:05 -0600 (MDT) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id HXdIhdgUreyBxHXdJh5HJI; Fri, 19 Apr 2019 11:49:05 -0600 X-Authority-Reason: nr=8 Original-Received: from [76.77.182.20] (port=52591 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hHXdI-000PK0-Qi for emacs-devel@gnu.org; Fri, 19 Apr 2019 11:49:04 -0600 In-Reply-To: <86sgwpuk2q.fsf@stephe-leake.org> (Stephen Leake's message of "Fri, 15 Feb 2019 07:50:53 -0800") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host114.hostmonster.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 76.77.182.20 X-Source-L: No X-Exim-ID: 1hHXdI-000PK0-Qi X-Source-Sender: (Takver4) [76.77.182.20]:52591 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 1 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDExNC5ob3N0bW9uc3Rlci5jb20= X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.33.93 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235667 Archived-At: 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