From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Alexander Adolf <alexander.adolf@condition-alpha.com>,
59314@debbugs.gnu.org
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Wed, 16 Nov 2022 11:46:00 -0800 [thread overview]
Message-ID: <878rka1y4n.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <m3iljeemj5.fsf@fitzsim.org> (Thomas Fitzsimmons's message of "Wed, 16 Nov 2022 14:18:06 -0500")
On 11/16/22 14:18 PM, Thomas Fitzsimmons wrote:
> Hi Eric,
>
> Thanks for filing this.
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Address completion in message-mode has stopped working in master,
>> possibly as a result of 0e25a39e69acca0324c326ea8e46b1725594bff5. This
>> has been reported for several contact-management backends that expect to
>> have their completions available with <TAB>.
>>
>> `completion-at-point-functions' contains '(eudc-capf-complete
>> message-completion-function t) at this point -- `eudc-capf-complete'
>> returns no matches, and no other functions in the list are consulted.
>
> I just checked and I didn't think the recent patch I pushed,
> 0e25a39e6..., should have affected completion-at-point-functions. It
> did change the default of eudc-server-hotlist from `nil' to
> `(("localhost" . ecomplete) ("localhost" . mailabbrev))". I thought
> that should only affect EUDC users who have not customized
> eudc-server-hotlist.
>
> `eudc-capf-complete' was added to `message-mode' in commit
> 620ac6735... I'm pretty sure that commenting out this line in
> message.el will restore prior behaviour, but I don't yet know what prior
> behaviour should be (see below).
>
> (add-hook 'completion-at-point-functions #'message-completion-function nil t)
>
>> On gnus.general, someone using BBDB and corfu reported that this recipe
>> fixed the problem:
>>
>> (setq eudc-server-hotlist '(("localhost" . bbdb)))
>>
>> (add-hook 'message-mode-hook
>> (lambda ()
>> (setq-local completion-at-point-functions
>> (delq 'message-completion-function
>> completion-at-point-functions))))
>>
>> Someone else *not* using corfu reported that that didn't work for them.
>> Dunno.
>
> I'm not sure what the out-of-the-box behaviour here is meant to be. Can
> you make a recipe starting from "emacs -Q" (including adding dummy email
> addresses somewhere) that makes completion work how you want it to? For
> me:
>
> emacs -Q
> C-x m TAB
>
> inserts four spaces and prints in *Messages*:
>
> Loading eudcb-ecomplete...done
> Loading eudcb-mailabbrev...done
>
> (Those are new, due to 0e25a39e6... but I thought should be harmless.)
Yuck, it's been a long time since I looked at this...
In emacs -Q, message-mode `completion-at-point-functions' is:
(eudc-capf-complete message-completion-function t)
Actually that's what it is in my regular Emacs, as well. All I'd need
for EBDB (and BBDB and everything else) is for
`message-completion-function' to get called, which it isn't. I believe
you could allow this by having `eudc-capf-complete' return nil, or have
`eudc-capf-message-expand-name' return a `(list beg end <table>)'
structure that includes the prop `:exclusive 'no' at the end of it. That
would allow a fallthrough to the next function.
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.
`message-completion-function' already looks at where it is in the
message buffer, and calls `message-expand-name' if it's in a "name"
header. That function consults `message-expand-name-databases', and
*that's* where EBDB should put its completion table, except
`message-expand-name-databases' is hardcoded to (or 'eudc 'bbdb) for no
reason.
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.
Eric
next prev parent reply other threads:[~2022-11-16 19:46 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 [this message]
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
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=878rka1y4n.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=59314@debbugs.gnu.org \
--cc=alexander.adolf@condition-alpha.com \
--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).