From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.bugs Subject: bug#59314: 29.0.50; EUDC and message-mode header completion Date: Thu, 01 Dec 2022 16:48:20 +0100 Message-ID: References: <87a64q7p25.fsf@ericabrahamsen.net> <878rka1y4n.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4604"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59314@debbugs.gnu.org To: Eric Abrahamsen , Thomas Fitzsimmons Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 01 16:49:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0loJ-00011a-8O for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 16:49:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0loF-0003Xu-KI; Thu, 01 Dec 2022 10:49:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0lo6-0003Uf-Qb for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 10:49:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p0lo5-0007ah-O0 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 10:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0lo5-0000TI-Jl for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 10:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alexander Adolf Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2022 15:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59314 X-GNU-PR-Package: emacs Original-Received: via spool by 59314-submit@debbugs.gnu.org id=B59314.16699097081805 (code B ref 59314); Thu, 01 Dec 2022 15:49:01 +0000 Original-Received: (at 59314) by debbugs.gnu.org; 1 Dec 2022 15:48:28 +0000 Original-Received: from localhost ([127.0.0.1]:40425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0lnY-0000T3-A8 for submit@debbugs.gnu.org; Thu, 01 Dec 2022 10:48:28 -0500 Original-Received: from smtprelay06.ispgateway.de ([80.67.18.29]:17710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0lnS-0000Ss-MJ for 59314@debbugs.gnu.org; Thu, 01 Dec 2022 10:48:26 -0500 Original-Received: from [46.244.208.80] (helo=condition-alpha.com) by smtprelay06.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p0lnR-0001ep-5u; Thu, 01 Dec 2022 16:48:21 +0100 In-Reply-To: <878rka1y4n.fsf@ericabrahamsen.net> X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249644 Archived-At: Hello Eric, Eric Abrahamsen 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