Tomi Ollila <tomi.oll...@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 _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org