[PATCH] proposal for message-mode email completion enhancements

[Alexander Adolf]

Hello Stefan,

I thought you would likely choose to have an opinion on this? ;-)

Cheers,

  --alexander

-------------------- Start of forwarded message --------------------
To: emacs-devel@gnu.org
Subject: [PATCH] proposal for message-mode email completion enhancements
Date: Sun, 30 Mar 2025 18:05:36 +0200
From: Alexander Adolf via "Emacs development discussions." <emacs-devel@gnu.org>

Dear Emacs community,

I wanted to get your views on a couple of - mainly under the bonnet -
enhancements to email address completion in message-mode.


Why did I work on this?

The root cause was switching my email workflow to notmuch
(https://notmuchmail.org), and the Emacs MUA package that notmuch
provides. I have some 1700 contacts in my CardDAV server, and I'm not
moving those anywhere else, as I need them synchronised across my
devices. Hence, the first thing I ended up doing was contributing a new
back-end for EUDC to enable it to access the contacts in the proprietary
CardDAV client I'm using (the macOS Contacts app).

This allowed me to advance to the second challenge: I wanted email
address completion to present me _combined_ candidates from EUDC, and
from notmuch-address.el (which is also provided by nomuch, and collects
email addresses from the messages indexed by notmuch). This proved to be
a more formidable challenge. First, message-mode integrates with EUDC,
ecomplete, mailabbrev, and bbdb for email address completion. Second,
the Emacs part of notmuch tries to be extra friendly with the company
Elisp package, and - to achieve that - modifies the value of
`message-completion-alist` in the init function of its
`notmuch-message-mode` (which is derived from `message-mode`).

A third party package taking "unorthodox measures" (apparently trying to
stick to diplomatic wording here) is nothing to blame on message-mode,
of course. What it does illustrate, however, is that with a growing
number of email address sources being integrated across message.el, it
becomes more and more difficult for third party package authors to
locate and use appropriate extension points for email address completion
in message.el.

There I was with all those loose ends in my hand, and `message-tab`
getting in my way more often than not.


What are the basic ideas behind the proposed changes?

- To remove integrations for all email address completion sources from
  message.el, except for EUDC.

- To point users to instead add relevant EUDC back-ends for ecomplete,
  mailabbrev, and bbdb to `eudc-server-hotlist`.

- To enable the use of completion categories when providing candidates
  for email address completion.


What are the advantages provided?

- The combining of completion candidates from various sources happens in
  EUDC, which provides a framework for doing this already. This
  simplifies the course of action in email address completion in
  message.el significantly.

- Message-mode integrating exclusively with EUDC for email address
  completion allows for re-removing historical additions to message.el
  for other email address sources, which simplifies the code in
  message.el, hopefully easing its future maintenance. It also provides
  a clear extension point (EUDC) for adding further sources for email
  addresses. As a bonus, writing a new back-end for EUDC is a
  considerably lower entry barrier for third party developers than
  finding the right functions to tweak in a 9000 line Elisp file.

- With EUDC being the single source, the behaviour is consistent between
  EUDC and message-mode. If you find the email address in one, you will
  find the exact same email address in the other.

- With the introduction of completion categories for email addresses
  (and newsgroups, too) in message-mode, users get better suited
  filtering of completion candidates. As the completion categories are
  user-configurable, users can use their own categories, too.

- Automatic marshalling of the completion source to use (and the
  associated completion category) when point is in a header requiring
  email recipients, in a header requiring newsgroups, or in a place
  requiring prose text, removes the need for any dwim-ish code bound to
  a key chord trying to make such heuristic assessments (such as for
  example `message-tab`). It is all handled by `completion-at-point`
  alone out of the box; it DTRT.


What are potential disadvantages?

- It will break user configs. Setups that use `message-tab`, or any of
  the existing email address source integrations (ecomplete, mailabbrev,
  bbdb) in message.el, will need to be updated. Replacements for all
  existing functionality are provided, however. No existing features are
  lost, they just need to be configured differently now.

- EUDC seems much under-esteemed, and not used by too many. Hence
  pointing users to a core package many may never have heard of, will
  probably cause some eyebrows to raise. ;-)


What are the next steps?

First and foremost, I'm looking forward to your thoughts, and comments
on both the ideas, and the implementation.

Second, there is still also some documentation work to do as I need to
scratch my head about a suitable NEWS entry, and figure out and make the
necessary modifications to the message-mode manual. I am putting those
two tasks off, however, until there will be consensus that this is a
useful and desirable thing to do, and that it is being implemented in an
acceptable way.


Many thanks and looking forward to your thoughts,

  --alexander

0001-Refactoring-Message-Completion-Alist.patch
Description: [PATCH] Refactoring Message-Completion-Alist

0002-Use-completion-at-point-and-EUDC-for-email-address.patch
Description: [PATCH] Use completion-at-point and EUDC for email address completion

0003-Drop-message-tab.patch
Description: [PATCH] Drop message-tab

-------------------- End of forwarded message --------------------