Utkarsh Singh <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
