Hello Alexander,

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

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

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

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:

(progn
  (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))
		  (point)))
	   (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)))

  (notmuch-mua-new-mail))

-- 
Utkarsh Singh
https://utkarshsingh.xyz/
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org