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





reply via email to

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