Utkarsh Singh <utkarsh190601@gmail.com> writes:

>>
>> Can you be more precise about what you are asking / proposing here?
>> Assume I only skimmed the thread.
>
> Currently, notmuch-address.el, the library used to generate completion
> candidates for recipient's addresses in Notmuch's message compostion
> mode uses non-standard Emacs API's for in-buffer completion, namely
> completing-read and Company.  Now these API's makes it difficult to
> utilize alternative in-buffer completion UI such as Corfu(1).

#'completing-read is of course standard since forever. We might be using
 it in some strange way, or it might be superceded by better things, but
completing-read is not non-standard.

>
> These are the proposed solutions for the given problem:
>
> 1. Add completion-at-point to the existing sets of frontend.  As noted
> by Tomi, this is a "messy" solution as it unnecessarily obfuscate the
> user options `notmuch-address-selection-function' and
> `notmuch-address-command'.
>
> 2. Make notmuch-address.el itself a backend for EUDC(2).  As stated by
> Alexander, this will not only remove any frontend related code from
> notmuch-address.el, but will also unify completion condidates for other
> sources such as BBDB, LDAP, MacOS Contacts, etc.
>

As a reviewer / release manager, I care about the amount of code
changes. As a user I hope my existing setup will keep working with no,
or (less good) minimal changes. Other than that I am open to ideas.

d
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org