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

[Stefan Monnier]

>>> And again, it doesn't have to be a separate command, the behavior
>>> could be customizable and dispatched inside the one command's
>>> implementation.
> I've now implemented this.
> Gnu ELPA has updated versions of path-iterator and uniquified-files.
> I added a new file completion style; file-root-rel, in
> uniquified-files/file-complete-root-relative.el.
>
> Attached is an elisp file demo-project-file-completion.el, which
> rewrites project--completing-read-strict to allow either the user or the
> project backend to specify the completion style, and provides examples
> of each of three styles:
[...]
>        (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.  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?

> 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ão, I think we should move from
completion-style-alist to using generic functions that dispatch on the style.

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").  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).

> 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).


        Stefan