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

[Stefan Monnier]

> 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<Alice/alice-1/>" 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<Alice/alice-1/>" 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