Re: [PATCH] emacs: Add more front ends for address completion

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Tue, Feb 08 2022, Utkarsh Singh wrote:
>
>> [...]
>>         Corfu enhances the default completion in region function with a
>>         completion overlay. The current candidates are shown in a popup
>>         below or above the point.  Corfu is the minimalistic
>>         ~completion-in-region~ counterpart of the
>>         [[https://github.com/minad/vertico][Vertico]] minibuffer UI.
>> [...]

I, too, have been intrigued by this package, and am currently exploring
it with an eye to replacing the company package for me. I have hit the
same wall with email address completion in (notmuch) message buffers as
the OP.

I think there could be a wider question lurking here: apart from
supporting those completion systems that the developers use, what could
be a reasonable, overall strategy towards handling completion?

A loosely related case could be indicative: my humble self has written a
new company back-end for EUDC (Emacs Universal Directory Client), so
that email addresses from LDAP servers could be offered as completion
candidates by email clients such as e.g. notmuch. I proposed it to the
company authors. Their response was that they (trying to word it
diplomatic here...) would discourage adding any further backends to
company. Instead, any new completion sources should hook themselves into
completion-at-point-functions, which in turn can be used as a source for
candidates by company. In fact, if they re-started company today, they
would do things completely differently; they'd create a pure UI
front-end, and use completion-at-point-functions as the one and only
source; so they said. Sounds a lot like corfu, doesn't it?

The completion topic tends to come up on emacs-devel in certain
intervals, too. Also there, the same complexity complaints are raised
against existing completion systems, and the number of fingers pointing
at completion-at-point-functions seems growing. Ok, not surprising,
given that it's emacs-devel; but still.

Hence, from my personal point of view, moving _all_ completion to go
through completion-at-point-functions seems the only reasonable way
forward.

That would remove any special cases for when company is available from
the elisp. Fewer third-party integrations, fewer headaches.

I don't think we would loose any functionality, as company can obtain
candidates from completion-at-point-functions. I.e. users could continue
to use company w/o losing any functionality. Also, there is a sister
package to corfu, which is called cape; which is from the same author.
It allows you to wrap company back-ends so they can be used in
completion-at-point-functions. This seems a decisive tool for the
migration to completion-at-point-functions, as it allows users to
re-purpose existing company back-ends, until their authors will have
migrated them to completion-at-point-functions.


Cheers,

  --alexander