Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
Alexander Adolf writes: > [...] > Variant 2 "core Emacs": > [...] It was not as much work as I had anticipated, and hence here is a first sketch of the idea: patch-notmuch-address.el Description: application/emacs-lisp Some further cleanup to remove all company stuff from notmuch-address.el would still be needed, though. Looking forward to your thoughts, --alexander ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
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 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
Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
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 cheers, Tomi ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
