Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> [...]
> 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 have further ventured into this, and am attempting to disable all
company-related stuff in notmuch-address.el, and instead go through
completion-at-point-functions, and use corfu as the completion UI.

To achieve this, I have set notmuch-address-use-company to nil, and
notmuch-address-command to 'as-is.

The latter setting (notmuch-address-command 'as-is) evokes an error:
"Wrong type argument: stringp, as-is". The backtrace led me to marvel at
the function notmuch-address-options (in notmuch-address.el). There, in
case notmuch-address-command is not equal to 'internal, control is
passed to notmuch--process-lines, which in turn uses 'as-is (a symbol)
as the name of an external program to call. The name of that command is
expected to be a string, and hence the "wrong type argument" error.

The docstring for notmuch-address-command does not really state any
other effects of 'as-is besides preventing modification of
message-completion-alist (which is what I want, and to keep using the
internal mechanism). The defcustom option for 'as-is is cunningly
labelled "Use default or third-party mechanism", which doesn't tell me
much more either.

Am I misreading notmuch-address.el and/or the docs?

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?


Many thanks in advance and cheers,

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