Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

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