Re: scratch/backend-completion c807121fbd 1/2: Add lisp/backend-completion.el

[Stefan Monnier]

>     This completion style is meant to be used with a "programmable
>     completion" table that interfaces with an external providing

An external .... ?

> +;; overriden.  This can be seen as a drawback, but, on the other hand,
> +;; the regular the full data set to be available in Emacs' addressing
> +;; space, which is often not feasible.

There something wrong around "the regular the full data".

> +;; The programmable completion table amounts to a function taking
> +;; (PATTERN PRED ACTION) as arguments respond to at least three values
> +;; for ACTION:
> +;;
> +;; * The symbol `metadata', where the table should reply with a list
> +;;   that looks like:
> +;;
> +;;      (metadata (category . backend-completion) MORE...)
> +;;
> +;;    where MORE... can be other "metadata" items like
> +;;    `cycle-sort-function'.
> +;;
> +;;    Other categories can be used in place of `backend-completion',
> +;;    as long as the `styles' property of such categories contains the
> +;;    sole element `backend-completion-backend-style'.

Hmmm... I don't think we should recommend `backend-completion` as
a category.  It is fundamentally wrong.  So I think `backend-completion`
should be the name of the completion style, and the category name should
reflect the user-facing category of elements being completed rather than
the internal details of how the completion is performed.

Maybe a good way to do that is to provide a (backend-completion-table
FUNC CATEGORY &optional METADATA) where FUN is a function which handles
the tryc and allc cases (maybe the `tryc` handling could even be
optional, depending on how the `tryc` case is usually handled (do
backends often provide something usable for `tryc`?)).  That function
would then return an appropriate completion-table (function), and would
make sure along the way that CATEGORY is mapped to `completion-backend`
in the `completion-category-defaults`.

That `backend-completion-table` would also have the benefit that it
could make sure the completion-table it returns also behaves sanely
with other styles (i.e. also handle the "normal" completion table
requests), whereas otherwise the temptation would be very high for users
of this package to use "completion table functions" which only handle
the `backend-completion-tryc/allc` requests and fail pathetically when
another style is used.  Similarly `backend-completion-table` could also
make sure PRED is obeyed.

>  (add-to-list 'completion-category-overrides
> -             '(eglot-indirection-joy (styles . (eglot--lsp-backend-style))))
> +             '(eglot-indirection-joy (styles . 
> (backend-completion-backend-style))))

Any reason not to call that completion category just `eglot`?


        Stefan