unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





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