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

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

Date: Wed, 23 Feb 2022 00:04:18 +0200

To: Alexander Adolf, Utkarsh Singh, Notmuch mailing list


From: Tomi Ollila

On Mon, Feb 21 2022, Alexander Adolf wrote:

> Alexander Adolf <> 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?

You are probably reading the code right. Probably all the combinations
notmuch-address variables can be set are not (throughly;) tested.

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

> Many thanks in advance and cheers,

>   --alexander


notmuch mailing list --
To unsubscribe send an email to