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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

I can't see why it wouldn't be just as general as what we have now.

    (defun backend-completion-table ( tryc-function allc-function
                                      category &optional metadata)
      (unless (assq category completion-category-defaults)
        (push `(,category (styles completion-backend))
              `completion-category-defaults))
      (lambda (string pred action)
        (pcase action
          (`metadata
           `(metadata (category . ,category) . ,metadata))
          (`(backend-completion-tryc . ,point)
           ;; FIXME: Obey `pred`?  Pass it to `tryc`?
           `(backend-completion-tryc . ,(funcall tryc string point)))
          (`(backend-completion-allc . ,point)
           (let ((all (funcall allc string point)))
             `(backend-completion-allc . ,(seq-filter pred all))))
          (`(boundaries . ,_) nil)
          (t
           (let ((all (funcall allc string (length string))))
             (complete-with-action action all string pred))))))

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

See above.

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

Wow!  I didn't pay attention at first, but I now see you're modifying
`completion-category-overrides` which is the user-facing variable.
You should modify `completion-category-defaults` instead!

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

I'm not very familiar with Eglot's code but based on a cursory check, it
seems this is used specifically when completing an identifier for things
like `xref`, so maybe `eglot-identifier` (and maybe `eglot` should be
renamed to `eglot-code` since it's used to complete the actual code in
the buffer)?


        Stefan