[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59314: 29.0.50; EUDC and message-mode header completion
From: |
Eric Abrahamsen |
Subject: |
bug#59314: 29.0.50; EUDC and message-mode header completion |
Date: |
Wed, 16 Nov 2022 18:04:06 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On 11/16/22 20:34 PM, Thomas Fitzsimmons wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>>
>>> 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.
>>
>> It does! Thanks.
>
> As I was considering reverting the default change, I figured that this
> is likely a bug in `eudc-capf-message-expand-name'; it should return nil
> if it gets no results from any EUDC backend, right? I pushed a fix for
> that. Can you apply it to your tree and see if your completion setup
> works again?
Yes that worked, rebuilt Emacs with no additional changes.
- bug#59314: 29.0.50; EUDC and message-mode header completion, Eric Abrahamsen, 2022/11/16
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/11/16
- bug#59314: 29.0.50; EUDC and message-mode header completion, Eric Abrahamsen, 2022/11/17
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/11/19
- bug#59314: 29.0.50; EUDC and message-mode header completion, Eric Abrahamsen, 2022/11/21
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/11/22
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/11/24
- bug#59314: 29.0.50; EUDC and message-mode header completion, Eric Abrahamsen, 2022/11/24
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/11/24