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, 15 Feb 2019 07:50:53 -0800 Message-ID: <86sgwpuk2q.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="179117"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 15 16:52:52 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 1gufnI-000kRJ-AR for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 16:52:52 +0100 Original-Received: from localhost ([127.0.0.1]:41917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gufnH-0002cf-4d for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 10:52:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gufmC-0002b9-99 for emacs-devel@gnu.org; Fri, 15 Feb 2019 10:51:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gufm4-000414-1F for emacs-devel@gnu.org; Fri, 15 Feb 2019 10:51:39 -0500 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:32780) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gufm0-0003B6-1w for emacs-devel@gnu.org; Fri, 15 Feb 2019 10:51:34 -0500 Original-Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 386C714043D for ; Fri, 15 Feb 2019 08:50:57 -0700 (MST) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id uflRgWSA0mds9uflRgJpHA; Fri, 15 Feb 2019 08:50:57 -0700 X-Authority-Reason: nr=8 Original-Received: from [76.77.182.20] (port=61859 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1guflQ-003Qzy-W4 for emacs-devel@gnu.org; Fri, 15 Feb 2019 08:50:57 -0700 In-Reply-To: <86wom5vlki.fsf@stephe-leake.org> (Stephen Leake's message of "Mon, 11 Feb 2019 17:31:57 -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: 1guflQ-003Qzy-W4 X-Source-Sender: (Takver4) [76.77.182.20]:61859 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: 69.89.20.226 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:233380 Archived-At: Stephen Leake writes: > Stefan Monnier writes: > >> >> As you mention in uniquify-files.el: >> >> (defun completion-get-data-string (user-string table pred) >> [...] >> ;; FIXME: This is ultimately called from >> ;; `completion-try-completion' or `completion-all-completions'; >> ;; there is only one style currently being used. Need to pass that >> ;; style from there to here. >> >> it only makes sense to call the conversion function corresponding to the >> style that was used to generate that string. >> >> [ Also while a specific call to minibuffer-complete (or >> minibuffer-completion-help, or minibuffer-force-complete, ...) only >> uses a single style, a given completing-read session can currently use >> several completion styles. ] >> >> So I think we should fix this FIXME before we can move this code to >> minibuffer.el. Maybe we can save the completion style that returned >> that string in a text-property, or even directly store the conversion >> function in there (so we don't need to extend completion-style-alist). > > ... completion-get-data-string is called after > completing-read-default, via uniq-file-completing-read-default-advice. > At that point, user-string was computed by the last style tried (ie > uniq-file-all-completions, which could set a text property), but I'm not > sure if it's copied (losing the text properties) in the middle > somewhere. I'll try it. This is now implemented, in ELPA. -- -- Stephe