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 14:47:47 -0800 Message-ID: <86imxkvfcc.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="210904"; 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 23:52:58 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 1gumLq-000sgG-GR for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 23:52:58 +0100 Original-Received: from localhost ([127.0.0.1]:48262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gumLp-00075V-1W for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 17:52:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gumL8-00075Q-Oi for emacs-devel@gnu.org; Fri, 15 Feb 2019 17:52:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gumL7-0007qL-Se for emacs-devel@gnu.org; Fri, 15 Feb 2019 17:52:14 -0500 Original-Received: from outbound-ss-348.hostmonster.com ([74.220.202.212]:33574 helo=gproxy6-pub.mail.unifiedlayer.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gumL7-0007pe-KV for emacs-devel@gnu.org; Fri, 15 Feb 2019 17:52:13 -0500 Original-Received: from CMGW (unknown [10.9.0.13]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 261951E2362 for ; Fri, 15 Feb 2019 15:47:54 -0700 (MST) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id umGwgOR7PeyBxumGwgy9VS; Fri, 15 Feb 2019 15:47:54 -0700 X-Authority-Reason: nr=8 Original-Received: from [76.77.182.20] (port=62016 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gumGv-002n1V-TX for emacs-devel@gnu.org; Fri, 15 Feb 2019 15:47:53 -0700 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: 1gumGv-002n1V-TX X-Source-Sender: (Takver4) [76.77.182.20]:62016 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: 74.220.202.212 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:233401 Archived-At: Stephen Leake writes: > 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. Except it also needs: (setq minibuffer-allow-text-properties t) -- -- Stephe