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 15:38:17 -0800 Message-ID: <86d0nsvd06.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> <86imxkvfcc.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="27423"; 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 Sat Feb 16 01:03:51 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 1gunSQ-0006zP-Eg for ged-emacs-devel@m.gmane.org; Sat, 16 Feb 2019 01:03:50 +0100 Original-Received: from localhost ([127.0.0.1]:49072 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gunSP-0001Of-Bi for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 19:03:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:32960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gunRm-0001OY-RS for emacs-devel@gnu.org; Fri, 15 Feb 2019 19:03:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gunRk-0006D6-VW for emacs-devel@gnu.org; Fri, 15 Feb 2019 19:03:10 -0500 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:33558) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gunRj-00065a-6e for emacs-devel@gnu.org; Fri, 15 Feb 2019 19:03:08 -0500 Original-Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id A930B1768DE for ; Fri, 15 Feb 2019 16:38:19 -0700 (MST) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id un3jgAB2GD8Rpun3jgZS3q; Fri, 15 Feb 2019 16:38:19 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason Original-Received: from [76.77.182.20] (port=62033 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gun3j-003AoY-EW for emacs-devel@gnu.org; Fri, 15 Feb 2019 16:38:19 -0700 In-Reply-To: <86imxkvfcc.fsf@stephe-leake.org> (Stephen Leake's message of "Fri, 15 Feb 2019 14:47:47 -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: 1gun3j-003AoY-EW X-Source-Sender: (Takver4) [76.77.182.20]:62033 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.23.142 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:233405 Archived-At: Stephen Leake writes: > 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) That's not enough. Despite that setting, when there is a single completion, minibuffer-force-complete calls completion--replace, which explicitly deletes all text properties from the minibuffer text. Then minibuffer-force-complete returns that text. In addition, minibuffer-force-complete unconditionally uses buffer-substring-no-properties to return the text. So that setting lies, and using text properties to pass the style to completion-get-data-string is not reliable. -- -- Stephe