Tomi, apologies for the delay in getting back to you. I'm moving office, so had a couple of other chores for having fun with. ;-)
Tomi Ollila <tomi.oll...@iki.fi> writes: > [...] >> In case not, how can I prevent modification of message-completion-alist >> by notmuch, and still have notmuch use the 'internal mechanism for >> generating address completion candidates? > > My guess would be some elisp is required... > [...] That's a very good first guess. Always. ;-D I'm happy to have a go at contributing a patch to enable users to use completion-at-point for address completion. What would be the least controversial way forward? I can currently think of two variants. Variant 1 "minimally invasive surgery": Adding a new, Boolean custom variable which controls modification of message-completion-alist. notmuch-address-setup would need to be modified to make use of it. Pros: "minimally invasive surgery" Cons: High entry barrier (the end user needs to define his/her own function producing a completion table for email addresses, and must hence have a good understanding of how both, notmuch-address.el, and completion-at-point work). notmuch-address-command 'as-is retains its not too stringently defined semantics. Variant 2 "core Emacs": Adding a new, choice type custom variable which controls the framework to use for address completion; possible values are "completing-read (minibuffer UI)", and "completion-at-point (in-buffer UI)". At the same time, notmuch-address-use-company and notmuch-address-command 'as-is would be deprecated. A new function would be added to notmuch-address.el, which returns a completion table for completion-at-point. notmuch-address-setup would then need to modified to add either said new function, or notmuch-address-expand-name to message-completion-alist, depending on the chosen completion framework type. Pros: Uses core Emacs functionality (completing-read, or completion-at-point), hence removes dependency on 3rd party packages, and thus would make notmuch-address.el (even) more future proof. High-level configuration option lowers entry barrier for end users (no knowledge of notmuch-address.el, or completion-at-point required). Cons: Paves the way for removing company from notmuch-address.el. Company can use completion-at-point as a back-end (company-capf), so end users can continue to use company if they wish, but need to adapt their configuration. Looking forward to your thoughts, --alexander _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org