From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Tue, 19 Feb 2019 12:45:43 -0500 Message-ID: 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="58940"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 19 18:46:33 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 1gw9TU-000FEu-OX for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2019 18:46:32 +0100 Original-Received: from localhost ([127.0.0.1]:52814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gw9TT-00078r-Oi for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2019 12:46:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gw9Sv-00078T-80 for emacs-devel@gnu.org; Tue, 19 Feb 2019 12:45:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gw9St-0007Of-Ue for emacs-devel@gnu.org; Tue, 19 Feb 2019 12:45:57 -0500 Original-Received: from [195.159.176.226] (port=55468 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gw9St-0007OU-M3 for emacs-devel@gnu.org; Tue, 19 Feb 2019 12:45:55 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gw9Sr-000EWZ-QP for emacs-devel@gnu.org; Tue, 19 Feb 2019 18:45:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:DvYzPYie3Lt9D5yoQWMZFeZkIgc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.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:233461 Archived-At: > Yes, because a collection should only specify a style if it cannot work > with other styles. I read this to mean that this collection-specified style would only be used by collections which are fundamentally "broken" (because unable to work as collection for any other style). I had the impression that such "broken" collections are very rare. Some collections may be partly broken (work poorly with some styles, e.g. because they can't show all the completions of an empty string), but that it's only/mostly due to the inadequacy of the current collection API and even in those cases, it still works acceptably for several completion styles. We definitely want to support the case where the collection works OK for most/many/some styles, where it also wants to provide its own style, and where we want the user to be able to override that (via completion-category-oiverrides). So even for those collections where only its own style works, it makes sense to use that same (overridable) mechanism rather than provide another. >> 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; I don't mean "of the current matches" but "of the entire collection". (try-completion "" collection) should return just that, so the completion-style does have access to it (unless the collection doesn't implement `try-completion` correctly for that case, but it seems that in the present situation we have control over the collection so we can make sure it works correctly). >> 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"). > > 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. IIUC this means you're using a different API than the normal completion-table API (e.g. in the normal API the return value of (try-completion STR COLL) should have STR as prefix and (all-completions STR COLL) should have as prefix the part of STR past the completion-boundary). So that means the interface between your collection and your completion-style is basically private and hence your 3 representation and the functions between them are also internal implementation choices. [ Yes, I realize, I'm kind of stating the obvious, since you said earlier that this collection only works with this style. ] BTW, I have some problems when trying your code: I started Emacs, loaded uniquify-files and then did M-: (locate-uniquified-file '("/usr/bin")) and when I type d? in the minibuffer, I get the list of matching *absolute* files in *Completions*. Is that the intended behavior? More to the point, the "user format" seems identical to the "data format". Am I doing something wrong? >> 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. What I meant is that when we call uniq-file-get-data-string we already know that the user string is a valid match, so there shouldn't be any need to search in the completion table. E.g. if it's "foo-file1.text" we should be able to just prepend the hidden common prefix to the output of uniq-file-to-table-input, no? Later you wrote: > This is now implemented, in ELPA. [...] > Except it also needs: > (setq minibuffer-allow-text-properties t) [...] And then: > That's not enough. Despite that setting, when there is a single > completion, minibuffer-force-complete calls completion--replace, We could fix completion--replace. It currently removes all properties, but that's just because it was easier, I think it only cares about visible properties, so we could be more careful to only remove the `face`, `invisible`, and `display` properties. > In addition, minibuffer-force-complete unconditionally uses > buffer-substring-no-properties to return the text. We could also try and change this. But thinking more about it, relying on text-properties is inconvenient and unnecessary: inconvenient because as we can see they tend to be unreliable (and there's always the chance that the user typed that part of the text anyway), and unnecessary because this kind of completion style (which rearranges the text of completion candidates) can't really be mixed with other styles (the resulting behavior would be rather weird), so we don't need to know which style generated the chunk of text, we just need to know whether our style is the (only) currently active one. I'm starting to wonder if "completion-style" is the right place to put this. E.g. after removing the common prefix and swapping the dir/file to file/dir the remaining completion operations could meaningfully use completion-styles, so maybe it's better thought as an extra layer between the completion style and the collection ... ... or something. Stefan