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: Mon, 11 Feb 2019 17:31:57 -0800 Message-ID: <86wom5vlki.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="68312"; 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 Tue Feb 12 02:38:18 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 1gtN1d-000HfH-O8 for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2019 02:38:17 +0100 Original-Received: from localhost ([127.0.0.1]:59437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtN1c-00055B-Nh for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 20:38:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtN0e-0004vQ-NR for emacs-devel@gnu.org; Mon, 11 Feb 2019 20:37:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtMwp-0007Hx-WC for emacs-devel@gnu.org; Mon, 11 Feb 2019 20:33:21 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:49144) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtMwi-000742-7D for emacs-devel@gnu.org; Mon, 11 Feb 2019 20:33:14 -0500 Original-Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 829B97B7AF8E4 for ; Mon, 11 Feb 2019 18:32:01 -0700 (MST) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id tMvZgHelnszDUtMvZgbHEj; Mon, 11 Feb 2019 18:32:01 -0700 X-Authority-Reason: nr=8 Original-Received: from [76.77.182.20] (port=58871 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gtMvZ-000AQt-6I for emacs-devel@gnu.org; Mon, 11 Feb 2019 18:32:01 -0700 In-Reply-To: (Stefan Monnier's message of "Mon, 11 Feb 2019 16:50:09 -0500") 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: 1gtMvZ-000AQt-6I X-Source-Sender: (Takver4) [76.77.182.20]:58871 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.25.95 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:233245 Archived-At: Stefan Monnier writes: >> (table-styles (cdr (assq 'styles (completion-metadata "" collection nil= )))) >> (completion-category-overrides >> (list (list 'project-file (cons 'styles >> (or table-styles >> project-file-completion-styles))))) >> >> ;; If the completion table is a list, or a function that does >> ;; not return styles metadata, we set completion-styles to >> ;; reflect the user choice. >> (completion-styles (if table-styles nil project-file-completion-styles)) > > This gives precedence to the collection's styles with no way for the > user to override this choice.=20 Yes, because a collection should only specify a style if it cannot work with other styles. For example, if you comment out the styles metadata in uniq-file-completion-table (line 717 in uniquify-files.el), and set (uniquify-test-project-completion-style 'uniquify-file) (project-file-completion-styles '(substring)), the completion does not work properly; you can complete on the basename, but not on the directory part. Similarly for the styles metadata in fc-root-rel-completion-table-iter. I need to come up with a concise explanation of when a completion table should return a style. In this demo, there are two user-setable variables to indicate completion style; uniquify-test-project-completion-style at the project backend level, project-file-completion-styles at the generic project level. The user can set either, so they always have a choice. That should be a general rule; if a project backend provides a completion table that requires a certain style, it should also provide a plain list so the user can choose the style. > This problem is the reason why I designed the current system to go > through the indirection of a category, making it possible for the user > to override the category's default styles via > completion-category-overrides. > >> The uniquify-file completion style works on a list of files; see the > [...] >> However, file-root-rel does not, because the root directory must be >> stored somewhere that is accessible from the completion code. > > I don't understand this. Why can't the completion style compute the > common-prefix? The root is _not_ the common prefix of the current matches; it's an arbitrary directory, nominally the single project root. In project--completing-read-strict, it's the common prefix of the entire collection, computed once at the start. If the style computed the common prefix on each match set, it might not be constant during the completion; it could get longer as the choices are narrowed. That does not happen in project--completing-read-strict in master, nor in file-root-rel. >> uniquify-files.el now adds two functions to completion-styles-alist, for >> converting strings from user to table input format, or user to data >> format. > > As I mentioned in another message to Jo=C3=A3o, I think we should move fr= om > completion-style-alist to using generic functions that dispatch on the > style. That makes sense. > Also, I don't quite understand why we need 2: they both seem to > implement the same direction of the conversion (i.e. from "user-string" > to "data-string").=20=20 No, "table input format" is not the same as "data format". See the header comments in uniquify-files; "table input" is the format required for the "string" parameter to the completion table functions; for both uniquify-file and file-root-rel it is "partial_dir/partial_basename". "data" is the format returned by all-completions; an absolute file name. > I see that uniq-file-get-data-string does more (i.e. it tries to find > the corresponding match if there's only one) but I don't understand > why you need to do that: this seems to do a kind of completion which > minibuffer-complete-and-exit should already have done (if > `require-match` is set) or which shouldn't be done (if `require-match` > is not set). The main computation in uniq-file-get-data-string is to return the absolute file name corresponding to the table input string. minibuffer-complete-and-exit can't do that, because it doesn't know how to convert the user string to the absolute file name; as far as it knows, "foo-file1.text" is not a valid completion for "c:/.../uniquify-file-resources/Alice/alice-1/foo-file1.text", because they are not string-equal. Another way to look at this; the minibuffer-level completion functions only have access to user format strings; ie "foo-file1.text". minibuffer-complete-and-exit could return that, but we want it to return the absolute file name, as the substring completion style does, when used on a list of absolute file names. >> Together with the advice on completing-read-default and >> test-completion, this could be moved to minibuffer.el. > > 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). If we move to a completion object storing various things, we can store it there. Which doesn't address making this work in emacs 26. Hmm. This FIXME comment lies; 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. Similarly for completion-to-table-input. --=20 -- Stephe