[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project--completing-read-strict breaks ada-mode project completion t

From: Stefan Monnier
Subject: Re: project--completing-read-strict breaks ada-mode project completion table
Date: Wed, 20 Feb 2019 21:00:43 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> 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.
> But then project backends that choose to provide a uniquify-file (or any
> other "broken") completion table won't "just work"; the user will have
> to set completion-category-default or -overrides to get completion to
> work (as illustrated by locate-uniquified-file; more below).

No, indeed we don't want that: we want that the
completion-table-provided style is used by default without the user
having to take any special steps.  But we also want it to be possible
for the user to specify some other style to use instead.

>>>> 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).
> Yes, that would work, and be horribly inefficient.

Indeed, it would only work acceptably if either the backend special
cases the "" case or the style is able to do enough caching.

>> 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<Alice/alice-1/>" we should be able to just prepend the
>> hidden common prefix to the output of uniq-file-to-table-input, no?
> Yes, but that common prefix is only stored implicitly in the table.
> If we had a completion object, we could store it there.

Ah, OK, so it's an artifact of limitations of the current API, makes sense.

> I guess by "mixing with other styles" you mean processing a list of
> styles; if we had (basic uniquify-files), for <tab> on an empty string
> 'basic' would present a list of absolute file names, but for <tab> after
> a string that matches some basename 'uniquify-files' would present
> uniquified file names. That would be confusing, and I now realize that's
> why I only specify one completion style.

Exactly: they're mutually incompatible (not necessary in the sense that
something will break, but in the sense that the result makes no sense
for the user).

> It will probably require editing minibuffer.el, but I'll think about it.

Right, I'm thinking from the point of view that minibuffer.el can be
changed at will.  If/when we figure out a clean solution there, we can
maybe think about how to try and make it work with current

> Note that uniq-file-completion-table is an optimization; the
> uniquify-file completion style does work with a list of absolute files,
> or any completion table function that returns such a list.

Indeed, thinking about the kind of manipulation done for your
uniquification, it seems like it pretty much requires to have the
complete list from the start (and to basically start by rewriting this
list from the data format to the user format on entry, then do normal
completion on this and then convert the final result back to data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]