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

[Thomas Fitzsimmons]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 11/16/22 15:54 PM, Thomas Fitzsimmons wrote:
>> 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.
>
> Also, I didn't mean that rant to be directed at you! I realized it might
> have come off that way.

No, I didn't interpret it that way; I appreciated you digging into the
complexity.  I still have to figure out how to hook in
`eudc-expand-try-all' so that all configured EUDC backends are attempted
by default.  (See the ERT idea in my other response).

Thanks,
Thomas