GNU bug report logs - #59314
29.0.50; EUDC and message-mode header completion

Previous Next

Full log

View this message in rfc822 format

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 59314 <at> debbugs.gnu.org
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Wed, 07 Dec 2022 23:10:06 +0100

[Message part 1 (text/plain, inline)]

Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> [...]
> If I remove this line from message.el:
>
> (add-hook 'completion-at-point-functions #'eudc-capf-complete -1 t)
>
> and rebuild Emacs, then my recipe works, via:
>
> message-tab -...-> message-expand-name -> eudc-expand-inline
>
> The EUDC multi-selector UI is invoked allowing me to choose between
> emacs-ert-test-3 and emacs-ert-test-4, and the full name and email
> address is inserted correctly.  This is with completion-styles left at
> its default value.
>
> So that's one code path validated, phew.
> [...]

There are two ends to this, I think.

For one, you are no longer adding `eudc-capf-complete` to
`completion-at-point-functions` in message mode. This seems fine given
that we are not there yet to make `eudc-capf-complete` the default thing
to happen in 29.

OTOH, `eudc-capf-complete` is now just sitting there for people to use
it. The docstring, and the NEWS entry advertise it for adding to
`completion-at-point-functions`. If & when someone does that, it won't
work as expected, as you & I just figured, because `completion-styles`
has a default value aimed at single-word replacements (such as for
programming language keywords, or prose words from a dictionary), but
not for more complex, multi-word replacements (such as email addresses).
The `substring` entry is needed for this use-case.

To make this work, I am hence attaching a patch (relative to the tip of
master as of this writing), which sets `completion-style` from
`eudc-capf-complete`. The modification is done when the user has not
modified its value (assuming that a sensible value will have been set by
the user). If you need a patch on top of the 29 branch, please don't
hesitate to drop me a note.


Hoping to have helped, and looking forward to your thoughts,

  --alexander

[0001-Set-completion-style-for-email-addresses-when-EUDC-c.patch (text/x-patch, inline)]

From a7c5eed95321c77d4e5069a508b4b16094f4a68d Mon Sep 17 00:00:00 2001
From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Date: Wed, 7 Dec 2022 23:07:11 +0100
Subject: [PATCH] Set completion-style for email addresses when EUDC
 contributes to CAPF

* lisp/net/eudc-capf.el (eudc-capf-complete): when the user has not
modified 'completion-styles', set it to a value better suited for
email address completion than the default setting (bug#59314)
---
 lisp/net/eudc-capf.el | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/lisp/net/eudc-capf.el b/lisp/net/eudc-capf.el
index e2bbd5b28b..5bd2c92441 100644
--- a/lisp/net/eudc-capf.el
+++ b/lisp/net/eudc-capf.el
@@ -104,7 +104,16 @@ eudc-capf-complete
   (if (and (seq-some #'derived-mode-p eudc-capf-modes)
            (let ((mail-abbrev-mode-regexp message-email-recipient-header-regexp))
              (mail-abbrev-in-expansion-header-p)))
-      (eudc-capf-message-expand-name)))
+      (progn
+        ;; FIXME: `completion-styles' is set to a value which seems
+        ;; better suited for email address completion if and when it
+        ;; has not been modified from it's default value (which is not
+        ;; well suited for this purpose).  This is needed until
+        ;; `message.el' will be updated to use completion categories.
+        (when (equal completion-styles
+                     (eval (car (get 'completion-styles 'standard-value))))
+          (setq-local completion-styles '(substring partial-completion)))
+        (eudc-capf-message-expand-name))))
 
 ;;;###autoload
 (defun eudc-capf-message-expand-name ()
-- 
2.38.1

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.