bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59314: 29.0.50; EUDC and message-mode header completion


From: Thomas Fitzsimmons
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Wed, 16 Nov 2022 15:54:11 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

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

Ah, OK, that's what happened then.  The most recent patch I pushed made
`eudc-server-hotlist' non-nil by default, which makes
`eudc-capf-message-expand-name' do something other than return nil.

Can you try just (setq eudc-server-hotlist nil) and confirm that avoids
the breakage?

If it does, I'll revert that part of the patch for now.

Thanks,
Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]