From: Alexander Adolf <alexander.adolf@condition-alpha.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>,
Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: 59314@debbugs.gnu.org
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Thu, 01 Dec 2022 16:48:20 +0100 [thread overview]
Message-ID: <bcee30cef48498ff7beae30e5bef571a@condition-alpha.com> (raw)
In-Reply-To: <878rka1y4n.fsf@ericabrahamsen.net>
Hello Eric,
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> [...]
> In fact this whole message-mode thing is an impossible tangle, burritos
> within burritos, and it would be great to get rid of it altogether.
> [...]
> So I need to clobber `message-expand-name' altogether.
>
> And EUDC having a function on `completion-at-point-functions' is
> wrapping yet another burrito outside the existing burritos, because now
> EUDC has a completion function both inside and outside message-mode's
> own completion machinery.
>
> In fact the docstring of `eudc-capf-message-expand-name' makes it sound
> like it thinks it's being called as part of `message-expand-name', but
> now it isn't -- it's being called as part of the capf machinery. Or
> rather, it could potentially be called in both places.
>
> I think a half-stick of dynamite is the only real solution.
> [...]
Perhaps we can be slightly more CONstructive that this. ;-)))
I am preparing a patch to message.el which refactors
`message-completion-alist` along the lines of this:
---------------------------- Begin Quote -----------------------------
(defcustom message-completion-alist
`((,message-newgroups-header-regexp . (:category newsgroup
:fieldsep-re "\\([:,]\\|^\\)[ \t]*"
:completions ,#'message-expand-group))
(,message-email-recipient-header-regexp . (:category email
:fieldsep-re "\\([:,]\\|^\\)[ \t]*"
:completions ,#'eudc-capf-message-expand-name)))
"Alist of (RE . RECIPE), defining completion contexts.
This variable controls how `message-completion-function' performs
in-buffer completion. RECIPE is either a function (deprecated),
or a plist.
When `message-completion-function' is invoked, and point is on a
line matching one of the REs in the alist, the settings in the
corresponding RECIPE are applied.
When RECIPE is a function, it is called for completion. RECIPE
should be a function that obeys the same rules as those of
`completion-at-point-functions'.
When RECIPE is a plist, the properties control how in-buffer
completion is performed. The following properties are currently
defined:
:category
The symbol defining the category in
`completion-category-defaults' to use for completion. Also
see `completion-category-overrides', and `completion-styles'.
:fieldsep-re
The regular expression to use when scanning backwards in the
buffer. All text between point, and any preceding text
matching this regular expression, will be used as the prefix
for finding completion candidates.
:completions
The function that provides completions, and that obeys the
same rules as those of `completion-at-point-functions'.
In-buffer completion will be performed as if
`completion-at-point-functions' had been set to this value."
:version "29.1"
:group 'message
:type '(alist :key-type regexp
:value-type (choice (plist)
(function
:tag "Completion function (deprecated)"))))
----------------------------- End Quote ------------------------------
As you can see, `eudc-capf-message-expand-name` effectively replaces
`message-expand-name` altogether:
---------------------------- Begin Quote -----------------------------
(make-obsolete 'message-expand-name 'eudc-capf-message-expand-name
"29.1")
----------------------------- End Quote ------------------------------
The patch goes on to remove everything relating to ecomplete,
mailabbrev, bbdb, and the likes from message.el, too. Get rid of all the
burritos, except one. The one and only source for email addresses in
message.el IMHO should be EUDC, and the one and only completion UI
should be whatever CAPF uses. Any and all sources for email addresses
should implement back-ends for EUDC, so they can be queried via EUDC,
which does the aggregation of results from the different sources, and
delivers it back to message.el as one lump.
EUDC backends: ldap ecomplete mailabbrev bbdb you-name-it
\________________________ ____________________________/
V
|
V
eudc-capf.el: eudc-capf-message-expand-name
|
V
message.el: message-completion-function
|
V
minibuffer.el completion-at-point
|
V
[ optional completion UI (for example corfu) ]
As you may imagine, this is a bigger patch, and I am discussing it on
emacs-devel with Stefan Monnier. So it'll still be a little while until
it might hopefully get merged, and the burritos unwrapped.
Many thanks and looking forward to your thoughts,
--alexander
next prev parent reply other threads:[~2022-12-01 15:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 18:05 bug#59314: 29.0.50; EUDC and message-mode header completion Eric Abrahamsen
2022-11-16 19:18 ` Thomas Fitzsimmons
2022-11-16 19:46 ` Eric Abrahamsen
2022-11-16 20:54 ` Thomas Fitzsimmons
2022-11-16 22:28 ` Eric Abrahamsen
2022-11-17 1:34 ` Thomas Fitzsimmons
2022-11-17 2:04 ` Eric Abrahamsen
2022-11-17 1:16 ` Eric Abrahamsen
2022-11-17 3:32 ` Thomas Fitzsimmons
2022-11-17 3:28 ` Thomas Fitzsimmons
2022-11-18 4:21 ` Eric Abrahamsen
2022-11-19 7:42 ` Thomas Fitzsimmons
2022-11-22 0:15 ` Eric Abrahamsen
2022-11-22 15:21 ` Thomas Fitzsimmons
2022-11-24 7:24 ` Thomas Fitzsimmons
2022-11-24 22:09 ` Eric Abrahamsen
2022-11-24 9:53 ` Thomas Fitzsimmons
2022-12-01 15:46 ` Alexander Adolf
2022-12-01 16:02 ` Eric Abrahamsen
2022-12-01 15:48 ` Alexander Adolf [this message]
2022-12-01 17:49 ` Eric Abrahamsen
2022-12-02 2:50 ` Thomas Fitzsimmons
2022-12-06 20:40 ` Alexander Adolf
2022-12-06 20:52 ` Thomas Fitzsimmons
2022-12-06 23:29 ` Alexander Adolf
2022-12-07 1:51 ` Thomas Fitzsimmons
2022-12-07 3:14 ` Thomas Fitzsimmons
2022-12-07 22:10 ` Alexander Adolf
2022-12-07 22:21 ` Thomas Fitzsimmons
2022-12-08 22:34 ` Alexander Adolf
2022-12-08 22:58 ` Thomas Fitzsimmons
2022-12-10 1:40 ` Alexander Adolf
2022-12-10 14:27 ` Thomas Fitzsimmons
2022-12-12 22:10 ` Alexander Adolf
2022-12-14 1:34 ` Thomas Fitzsimmons
2022-12-14 18:07 ` Alexander Adolf
2022-12-15 3:32 ` Thomas Fitzsimmons
2022-12-19 16:09 ` Alexander Adolf
2022-12-21 17:39 ` Thomas Fitzsimmons
2022-12-11 16:08 ` Alexander Adolf
2022-12-12 12:31 ` Thomas Fitzsimmons
2022-12-07 22:20 ` Alexander Adolf
2023-02-11 3:30 ` Thomas Fitzsimmons
2023-01-31 13:04 ` Julien Cubizolles
2023-02-05 0:48 ` Thomas Fitzsimmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bcee30cef48498ff7beae30e5bef571a@condition-alpha.com \
--to=alexander.adolf@condition-alpha.com \
--cc=59314@debbugs.gnu.org \
--cc=eric@ericabrahamsen.net \
--cc=fitzsim@fitzsim.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).