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

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

tool

>> +;; 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 regular styles require the full data set", obviously.  Geez, can't
you read moronese?

>> +;; 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`.

I get the idea, I think.  I thought about this, but I'm not sure this
can be made generic enough to service the three examples I know of:
Eglot, SLY and the eel.el thing I've been using lately.

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

Alright.  But please, follow up with some code.  You're probably right,
but this whole thing is too complicated for me to understand.

If it helps, use the current Eglot.el code as an example client of that
new thing.

Or you can assume I also have another function:

   (defun eel (pattern) ...)

That returns a list of completions from an HTTP server (blockingly,
sometimes slowly) or may returns the symbols 'user-input', 'timeout'
depending on whether whether these two events happened before the
completions became available.  'eel' knows how the HTTP server matches
STRINGS and propertizes the strings it returns.

How would I plug this 'eel' function into the backend-completion-table
function you're envisioning?  And would it return a working table with
the backend completion style that I can put wherever (most likely
completing-read)?

>>  (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`?

Yes, 'eglot' is already a different completion category, for
completion-at-point, with a different structure.
`eglot-indirection-joy' is just a product of my usual confusion with
this whole jungle of concepts: I just vaguely understand it's an
indirection so I called it accordingly for mental reference.  But feel
free to suggest a better name.

João