Hello Alexander,

On 2022-02-12, 17:09 +0100, Alexander Adolf 
<alexander.ad...@condition-alpha.com> wrote:

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

First of all, apologies for the late reply and thank you for your

Currently I'm trying to prepare a patch which will remove all Company
specific calls with standard Emacs API.  For now, evaluate the following
expression to review the user-side changes:

  (add-to-list 'load-path "/usr/share/emacs/site-lisp")
  (require 'notmuch)

  (defun notmuch-address-expand-name ()
    (let* ((end (point))
           (beg (save-excursion
                  (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*")
                  (goto-char (match-end 0))
           (orig (buffer-substring-no-properties beg end))
           (completion-ignore-case t)
           (options (with-temp-message "Looking for completion candidates..."
                      (notmuch-address-options orig))))
      (list beg end options)))


Utkarsh Singh
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Reply via email to