unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59314: 29.0.50; EUDC and message-mode header completion
@ 2022-11-16 18:05 Eric Abrahamsen
  2022-11-16 19:18 ` Thomas Fitzsimmons
  0 siblings, 1 reply; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-16 18:05 UTC (permalink / raw)
  To: 59314; +Cc: fitzsim


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.

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.

Eric





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  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
  0 siblings, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-16 19:18 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

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

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 19:18 ` Thomas Fitzsimmons
@ 2022-11-16 19:46   ` Eric Abrahamsen
  2022-11-16 20:54     ` Thomas Fitzsimmons
                       ` (3 more replies)
  0 siblings, 4 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-16 19:46 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314


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





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 19:46   ` Eric Abrahamsen
@ 2022-11-16 20:54     ` Thomas Fitzsimmons
  2022-11-16 22:28       ` Eric Abrahamsen
  2022-11-17  1:16       ` Eric Abrahamsen
  2022-11-17  3:28     ` Thomas Fitzsimmons
                       ` (2 subsequent siblings)
  3 siblings, 2 replies; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-16 20:54 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

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





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 20:54     ` Thomas Fitzsimmons
@ 2022-11-16 22:28       ` Eric Abrahamsen
  2022-11-17  1:34         ` Thomas Fitzsimmons
  2022-11-17  1:16       ` Eric Abrahamsen
  1 sibling, 1 reply; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-16 22:28 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314

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.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 20:54     ` Thomas Fitzsimmons
  2022-11-16 22:28       ` Eric Abrahamsen
@ 2022-11-17  1:16       ` Eric Abrahamsen
  2022-11-17  3:32         ` Thomas Fitzsimmons
  1 sibling, 1 reply; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-17  1:16 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314


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.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 22:28       ` Eric Abrahamsen
@ 2022-11-17  1:34         ` Thomas Fitzsimmons
  2022-11-17  2:04           ` Eric Abrahamsen
  0 siblings, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-17  1:34 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

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?

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-17  1:34         ` Thomas Fitzsimmons
@ 2022-11-17  2:04           ` Eric Abrahamsen
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-17  2:04 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314


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.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 19:46   ` Eric Abrahamsen
  2022-11-16 20:54     ` Thomas Fitzsimmons
@ 2022-11-17  3:28     ` Thomas Fitzsimmons
  2022-11-18  4:21       ` Eric Abrahamsen
  2022-12-01 15:46     ` Alexander Adolf
  2022-12-01 15:48     ` Alexander Adolf
  3 siblings, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-17  3:28 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

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

Should we set `message-expand-name-databases' to (or 'eudc 'bbdb 'ebdb)?
Would that avoid the need to clobber `message-expand-name' for your use
case?  I'd be fine adding "known packages" there, as long as referring
to non-core packages doesn't break anything (which it doesn't seem to,
since BBDB is non-core, in GNU ELPA).

> So I need to clobber `message-expand-name' altogether.

When I use EUDC, I too clobber `message-mode's completion, by binding
TAB to `eudc-expand-try-all'.  Part of the effort around eudc-capf was
trying to improve the default so that this clobbering wouldn't be
necessary.  But as you point out, we're not there yet.

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

Agreed it's currently hard to navigate, but I'd prefer to take minimal
steps from what we have now, since people have configurations that
depend on the current state.

I think we should probably create a set of core "out-of-the-box"
`message-mode' completion ERT tests.  For example, given:

"emacs -Q" + EBDB + a single EBDB entry "emacs-ert-test@ebdb.gnu.org"

will "C-x m emacs TAB" work?  If it won't, will the above-suggested
`message-expand-name-databases' make it work?

Once we get "emacs-ert-test" examples for @bbdb.gnu.org,
@ecomplete.gnu.org, @mailabbrev.gnu.org, we'll be able to test how the
various completion backends interact, and I'm thinking that will help us
simplify TAB's default behaviour in `message-mode' (while preserving
backward compatibility).

Do you want to try adding a core ERT test for EBDB completion?  Optional
core tests are allowed to depend on GNU ELPA packages.

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-17  1:16       ` Eric Abrahamsen
@ 2022-11-17  3:32         ` Thomas Fitzsimmons
  0 siblings, 0 replies; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-17  3:32 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

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





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-17  3:28     ` Thomas Fitzsimmons
@ 2022-11-18  4:21       ` Eric Abrahamsen
  2022-11-19  7:42         ` Thomas Fitzsimmons
  0 siblings, 1 reply; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-18  4:21 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314

[-- Attachment #1: Type: text/plain, Size: 8637 bytes --]


On 11/16/22 22:28 PM, Thomas Fitzsimmons wrote:
> 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.
>>
>> 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.
>
> Should we set `message-expand-name-databases' to (or 'eudc 'bbdb 'ebdb)?
> Would that avoid the need to clobber `message-expand-name' for your use
> case?  I'd be fine adding "known packages" there, as long as referring
> to non-core packages doesn't break anything (which it doesn't seem to,
> since BBDB is non-core, in GNU ELPA).

I don't think that option should be aware of any contact management
packages at all! I'm attaching a patch that gets message.el about
halfway to where I think it ought to be: any such packages should be
able to push their own function onto `message-expand-name-databases'.

This patch allows that while maintaining some backwards compatibility.
The whole

(and (functionp (car message-expand-name-databases))
     (funcall (car message-expand-name-databases)))

part inside `message-expand-name' verges on nonsense, but that 
function is very weird anyway, in that it allows multiple values in
`message-expand-name-databases' but only ever consults one of them.

I hope that the behavior hidden behind `message-expand-name-standard-ui'
becomes the new norm at some point.

Right now, if EBDB or some other package pushed a function to
`message-expand-name-databases', that function would have to behave
differently depending on whether it's called by `message-expand-name' or
called as a part of `message--name-table', but it could reliably do that
by checking if `message-expand-name-standard-ui' is non-nil or not.

One thing that might be difficult under the standard ui is the extended
cycling that BBDB/EBDB offer: expanding the initial string to a contact,
and *then* cycle through that contact's multiple mail addresses, any one
of which might not match the initial string at all. But one thing at a
time.

>> So I need to clobber `message-expand-name' altogether.
>
> When I use EUDC, I too clobber `message-mode's completion, by binding
> TAB to `eudc-expand-try-all'.  Part of the effort around eudc-capf was
> trying to improve the default so that this clobbering wouldn't be
> necessary.  But as you point out, we're not there yet.

I guess I don't know why you need to push `eudc-capf-complete' to
`completion-at-point-functions', when EUDC is already enabled within
`message-complete-name'.

Right now `message-completion-function' does the work of detecting where
in the message buffer point is, and delegating to different functions
depending on the result. That seems reasonable to me, as the structure
of a message buffer is message-mode's business, and other programs
shouldn't need to duplicate the work of parsing text around point. Once
we've called `message-expand-name', though, I think we should be going
back to the built-in completion machinery of merging multiple completion
tables.

If EUDC is called as a part of `message-expand-name', that seems like
enough to me. Take a hypothetical user who for some reason wants to use
*both* BBDB and EBDB. They have the choice of plugging both packages
into EUDC and simply setting `message-expand-name-databases' to '(eudc).
Or they could set it to '(bbdb ebdb-complete-mail). Or heck, they could
use BBDB via EUDC, and then set it to '(eudc ebdb-complete-mail), why
not.

Doesn't that seem like enough?

>> 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.
>
> Agreed it's currently hard to navigate, but I'd prefer to take minimal
> steps from what we have now, since people have configurations that
> depend on the current state.
>
> I think we should probably create a set of core "out-of-the-box"
> `message-mode' completion ERT tests.  For example, given:
>
> "emacs -Q" + EBDB + a single EBDB entry "emacs-ert-test@ebdb.gnu.org"
>
> will "C-x m emacs TAB" work?  If it won't, will the above-suggested
> `message-expand-name-databases' make it work?
>
> Once we get "emacs-ert-test" examples for @bbdb.gnu.org,
> @ecomplete.gnu.org, @mailabbrev.gnu.org, we'll be able to test how the
> various completion backends interact, and I'm thinking that will help us
> simplify TAB's default behaviour in `message-mode' (while preserving
> backward compatibility).
>
> Do you want to try adding a core ERT test for EBDB completion?  Optional
> core tests are allowed to depend on GNU ELPA packages.

If we allow (and eventually expect) `message-expand-name-databases' to
contain a list of functions, I imagine the ERT test will just define its
own dummy function/data, and test that expansion happens correctly.

Hope all this isn't too obnoxious,
Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-name-databases.diff --]
[-- Type: text/x-patch, Size: 2816 bytes --]

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 3bbd68bdcd..e609aa7405 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -8266,9 +8266,11 @@ message-completion-alist
 (defcustom message-expand-name-databases
   '(bbdb eudc)
   "List of databases to try for name completion (`message-expand-name').
-Each element is a symbol and can be `bbdb' or `eudc'."
+Each element can be the symbol `bbdb', the symbol `eudc', or a function."
   :group 'message
-  :type '(set (const bbdb) (const eudc)))
+  :version "29.1"
+  :type '(repeat
+          (choice (const bbdb) (const eudc) function)))
 
 (defcustom message-tab-body-function nil
   "Function to execute when `message-tab' (TAB) is executed in the body.
@@ -8379,6 +8381,8 @@ message-expand-name
                ;; completion took place.  So let's double check the buffer was
                ;; not modified.
                (/= starttick (buffer-modified-tick)))))
+        ((and (functionp (car message-expand-name-databases))
+              (funcall (car message-expand-name-databases))))
 	(t
 	 (expand-abbrev))))
 
@@ -8408,26 +8412,28 @@ message--bbdb-query-with-words
 
 (defun message--name-table (orig-string)
   (let ((orig-words (split-string orig-string "[ \t]+"))
-        eudc-responses
-        bbdb-responses)
+        database-responses)
     (lambda (string pred action)
       (pcase action
         ('metadata '(metadata (category . email)))
         ('lambda t)
         ((or 'nil 't)
          (when orig-words
-           (when (and (memq 'eudc message-expand-name-databases)
-		      (boundp 'eudc-protocol)
-		      eudc-protocol)
-	     (setq eudc-responses (eudc-query-with-words orig-words)))
-	   (when (memq 'bbdb message-expand-name-databases)
-	     (setq bbdb-responses (message--bbdb-query-with-words orig-words)))
+           (dolist (db message-expand-name-databases)
+             (push
+              (pcase db
+                ((and `eudc (guard (bound-and-true-p eudc-protocol)))
+                 (eudc-query-with-words orig-words))
+                (`bbdb (message--bbdb-query-with-words orig-words))
+                ((pred functionp) (funcall db orig-words)))
+              database-responses))
 	   (ecomplete-setup)
 	   (setq orig-words nil))
          (let ((candidates
 	        ;; FIXME: Add `expand-abbrev'!
-	        (append (all-completions string eudc-responses pred)
-	                (all-completions string bbdb-responses pred)
+	        (append (mapcan (lambda (resp)
+                                  (all-completions string resp pred))
+                                database-responses)
 	                (when (and (bound-and-true-p ecomplete-database)
 	                           (fboundp 'ecomplete-completion-table))
                           (all-completions string

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-18  4:21       ` Eric Abrahamsen
@ 2022-11-19  7:42         ` Thomas Fitzsimmons
  2022-11-22  0:15           ` Eric Abrahamsen
  0 siblings, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-19  7:42 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 11/16/22 22:28 PM, Thomas Fitzsimmons wrote:
>> 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.
>>>
>>> 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.
>>
>> Should we set `message-expand-name-databases' to (or 'eudc 'bbdb 'ebdb)?
>> Would that avoid the need to clobber `message-expand-name' for your use
>> case?  I'd be fine adding "known packages" there, as long as referring
>> to non-core packages doesn't break anything (which it doesn't seem to,
>> since BBDB is non-core, in GNU ELPA).
>
> I don't think that option should be aware of any contact management
> packages at all! I'm attaching a patch that gets message.el about
> halfway to where I think it ought to be: any such packages should be
> able to push their own function onto `message-expand-name-databases'.
>
> This patch allows that while maintaining some backwards compatibility.
> The whole
>
> (and (functionp (car message-expand-name-databases))
>      (funcall (car message-expand-name-databases)))
>
> part inside `message-expand-name' verges on nonsense, but that 
> function is very weird anyway, in that it allows multiple values in
> `message-expand-name-databases' but only ever consults one of them.
>
> I hope that the behavior hidden behind `message-expand-name-standard-ui'
> becomes the new norm at some point.
>
> Right now, if EBDB or some other package pushed a function to
> `message-expand-name-databases', that function would have to behave
> differently depending on whether it's called by `message-expand-name' or
> called as a part of `message--name-table', but it could reliably do that
> by checking if `message-expand-name-standard-ui' is non-nil or not.
>
> One thing that might be difficult under the standard ui is the extended
> cycling that BBDB/EBDB offer: expanding the initial string to a contact,
> and *then* cycle through that contact's multiple mail addresses, any one
> of which might not match the initial string at all. But one thing at a
> time.
>
>>> So I need to clobber `message-expand-name' altogether.
>>
>> When I use EUDC, I too clobber `message-mode's completion, by binding
>> TAB to `eudc-expand-try-all'.  Part of the effort around eudc-capf was
>> trying to improve the default so that this clobbering wouldn't be
>> necessary.  But as you point out, we're not there yet.
>
> I guess I don't know why you need to push `eudc-capf-complete' to
> `completion-at-point-functions', when EUDC is already enabled within
> `message-complete-name'.
>
> Right now `message-completion-function' does the work of detecting where
> in the message buffer point is, and delegating to different functions
> depending on the result. That seems reasonable to me, as the structure
> of a message buffer is message-mode's business, and other programs
> shouldn't need to duplicate the work of parsing text around point. Once
> we've called `message-expand-name', though, I think we should be going
> back to the built-in completion machinery of merging multiple completion
> tables.
>
> If EUDC is called as a part of `message-expand-name', that seems like
> enough to me. Take a hypothetical user who for some reason wants to use
> *both* BBDB and EBDB. They have the choice of plugging both packages
> into EUDC and simply setting `message-expand-name-databases' to '(eudc).
> Or they could set it to '(bbdb ebdb-complete-mail). Or heck, they could
> use BBDB via EUDC, and then set it to '(eudc ebdb-complete-mail), why
> not.
>
> Doesn't that seem like enough?
>
>>> 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.
>>
>> Agreed it's currently hard to navigate, but I'd prefer to take minimal
>> steps from what we have now, since people have configurations that
>> depend on the current state.
>>
>> I think we should probably create a set of core "out-of-the-box"
>> `message-mode' completion ERT tests.  For example, given:
>>
>> "emacs -Q" + EBDB + a single EBDB entry "emacs-ert-test@ebdb.gnu.org"
>>
>> will "C-x m emacs TAB" work?  If it won't, will the above-suggested
>> `message-expand-name-databases' make it work?
>>
>> Once we get "emacs-ert-test" examples for @bbdb.gnu.org,
>> @ecomplete.gnu.org, @mailabbrev.gnu.org, we'll be able to test how the
>> various completion backends interact, and I'm thinking that will help us
>> simplify TAB's default behaviour in `message-mode' (while preserving
>> backward compatibility).
>>
>> Do you want to try adding a core ERT test for EBDB completion?  Optional
>> core tests are allowed to depend on GNU ELPA packages.
>
> If we allow (and eventually expect) `message-expand-name-databases' to
> contain a list of functions, I imagine the ERT test will just define its
> own dummy function/data, and test that expansion happens correctly.
>
> Hope all this isn't too obnoxious,

I'm experimenting with this area; thanks for the patch.

I'm first trying to get sensible default behaviour just from EUDC and
its backends.  (eudcb-mailabbrev doesn't work for me, in particular in
the case of an empty .mailrc file.  Alexander seems to be offline
nowadays, unfortunately.  I have a patch that simplifies
eudc-mailabbrev-query-internal considerably (and makes it work how I
think it should), but I'd probably want Alexander to review it.
Likewise with the capf functionality he added.  I'll give him a little
while longer to reply, but I may just proceed, since I'd like to make
this more solid before Emacs 29.1 is released).

I wouldn't actually propose doing the following, but to give you a sense
of my perspective I'll say: my inclination would be to replace the
binding:

TAB 'message-tab

with

TAB 'eudc-expand-try-all

That's what I actually do, with eudc-server-list containing a BBDB entry
followed by an LDAP entry.  I press "TAB" to complete entries that I'm
pretty sure are locally stored in my BBDB database.  If there is no
entry in BBDB, that will fall back to looking in LDAP.

To force getting all results from both BBDB and LDAP, I do: C-u TAB

That's the extent of my email completion setup.  I think the only reason
this setup doesn't generalize (assuming an EUDC EBDB backend in your
case) is that other people like different UIs, e.g., when the same
prefix expands to multiple possible addresses (as you alluded to), what
UI should one use to select?  I use the UI provided by EUDC.

Anyway, tonight I did manage to add ERT tests for the EUDC LDAP backend.
Can you try:

make -C test lisp/net/eudc-tests.log

on your machine to confirm they work for you?  You need /usr/sbin/slapd
installed.

I'll work on adding EUDC BBDB backend tests, and I may write an EBDB
EUDC backend.

Once I have that, I'll be able to extract all the configuration
resources (like .mailrc, ecompleterc, etc.) into a tarball.  Then we can
use that tarball to debug/redesign out-of-the-box completion scenarios,
starting from "emacs -Q + tarball", "emacs -Q + EBDB + tarball",
"emacs -Q + BBDB + tarball", etc.

Without starting from "emacs -Q", it's impossible for me to know what I
might break in other people's configurations, when making changes to
message-mode's default completion code.

Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-19  7:42         ` Thomas Fitzsimmons
@ 2022-11-22  0:15           ` Eric Abrahamsen
  2022-11-22 15:21             ` Thomas Fitzsimmons
  2022-11-24  9:53             ` Thomas Fitzsimmons
  0 siblings, 2 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-22  0:15 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:


[...]

> That's the extent of my email completion setup.  I think the only reason
> this setup doesn't generalize (assuming an EUDC EBDB backend in your
> case) is that other people like different UIs, e.g., when the same
> prefix expands to multiple possible addresses (as you alluded to), what
> UI should one use to select?  I use the UI provided by EUDC.
>
> Anyway, tonight I did manage to add ERT tests for the EUDC LDAP backend.
> Can you try:
>
> make -C test lisp/net/eudc-tests.log

No love!

Running 11 tests (2022-11-21 16:04:40-0800, selector `(not (or (tag :unstable) (tag :nativecomp)))')
   passed   1/11  eudc--plist-member (0.000396 sec)
   passed   2/11  eudc-lax-plist-get (0.000433 sec)
   passed   3/11  eudc-plist-get (0.000417 sec)
   passed   4/11  eudc-plist-member (0.000390 sec)
   passed   5/11  eudc-test-make-address (0.000151 sec)
   passed   6/11  eudc-test-rfc5322-quote-phrase (0.000067 sec)
   passed   7/11  eudc-test-rfc5322-valid-comment-p (0.000760 sec)
  skipped   8/11  eudcb-bbdb (0.000102 sec)
   passed   9/11  eudcb-ecomplete (0.007451 sec)
Loading eudcb-ldap...
Parsing results...
Parsing results... done
Parsing results...
Parsing results... done
Test eudcb-ldap backtrace:
  signal(error ("No match"))
  apply(signal (error ("No match")))
  (setq value-640 (apply fn-638 args-639))
  (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq form-
  (if (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq f
  (let (form-description-642) (if (unwind-protect (setq value-640 (app
  (let ((value-640 'ert-form-evaluation-aborted-641)) (let (form-descr
  (let* ((fn-638 #'equal) (args-639 (condition-case err (let ((signal-
  (let ((ldap-process (start-process "slapd" "*slapd*" "/usr/sbin/slap
  (closure (t) nil (let ((value-636 (gensym "ert-form-evaluation-abort
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name eudcb-ldap :documentation "Test the L
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
  ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
  ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
  eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/eudc-tests.el" "
  command-line()
  normal-top-level()
Test eudcb-ldap condition:
    (error "No match")
   FAILED  10/11  eudcb-ldap (1.024022 sec) at lisp/net/eudc-tests.el:271
Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc...
Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc... done
   passed  11/11  eudcb-mailabbrev (0.002174 sec)

Ran 11 tests, 9 results as expected, 1 unexpected, 1 skipped (2022-11-21 16:04:41-0800, 1.151547 sec)

1 unexpected results:
   FAILED  eudcb-ldap

1 skipped results:
  SKIPPED  eudcb-bbdb


> on your machine to confirm they work for you?  You need /usr/sbin/slapd
> installed.
>
> I'll work on adding EUDC BBDB backend tests, and I may write an EBDB
> EUDC backend.
>
> Once I have that, I'll be able to extract all the configuration
> resources (like .mailrc, ecompleterc, etc.) into a tarball.  Then we can
> use that tarball to debug/redesign out-of-the-box completion scenarios,
> starting from "emacs -Q + tarball", "emacs -Q + EBDB + tarball",
> "emacs -Q + BBDB + tarball", etc.
>
> Without starting from "emacs -Q", it's impossible for me to know what I
> might break in other people's configurations, when making changes to
> message-mode's default completion code.

I've already said this, but I don't think we should be pushing things in
a direction that relies any external package or its particular behavior.
The capf machinery should be enough, and that's very clearly defined.

Eric





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-22  0:15           ` Eric Abrahamsen
@ 2022-11-22 15:21             ` Thomas Fitzsimmons
  2022-11-24  7:24               ` Thomas Fitzsimmons
  2022-11-24  9:53             ` Thomas Fitzsimmons
  1 sibling, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-22 15:21 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
> [...]
>
>> That's the extent of my email completion setup.  I think the only reason
>> this setup doesn't generalize (assuming an EUDC EBDB backend in your
>> case) is that other people like different UIs, e.g., when the same
>> prefix expands to multiple possible addresses (as you alluded to), what
>> UI should one use to select?  I use the UI provided by EUDC.
>>
>> Anyway, tonight I did manage to add ERT tests for the EUDC LDAP backend.
>> Can you try:
>>
>> make -C test lisp/net/eudc-tests.log
>
> No love!
>
> Running 11 tests (2022-11-21 16:04:40-0800, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>    passed   1/11  eudc--plist-member (0.000396 sec)
>    passed   2/11  eudc-lax-plist-get (0.000433 sec)
>    passed   3/11  eudc-plist-get (0.000417 sec)
>    passed   4/11  eudc-plist-member (0.000390 sec)
>    passed   5/11  eudc-test-make-address (0.000151 sec)
>    passed   6/11  eudc-test-rfc5322-quote-phrase (0.000067 sec)
>    passed   7/11  eudc-test-rfc5322-valid-comment-p (0.000760 sec)
>   skipped   8/11  eudcb-bbdb (0.000102 sec)
>    passed   9/11  eudcb-ecomplete (0.007451 sec)
> Loading eudcb-ldap...
> Parsing results...
> Parsing results... done
> Parsing results...
> Parsing results... done
> Test eudcb-ldap backtrace:
>   signal(error ("No match"))
>   apply(signal (error ("No match")))
>   (setq value-640 (apply fn-638 args-639))
>   (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq form-
>   (if (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq f
>   (let (form-description-642) (if (unwind-protect (setq value-640 (app
>   (let ((value-640 'ert-form-evaluation-aborted-641)) (let (form-descr
>   (let* ((fn-638 #'equal) (args-639 (condition-case err (let ((signal-
>   (let ((ldap-process (start-process "slapd" "*slapd*" "/usr/sbin/slap
>   (closure (t) nil (let ((value-636 (gensym "ert-form-evaluation-abort
>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>   ert-run-test(#s(ert-test :name eudcb-ldap :documentation "Test the L
>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>   ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
>   ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
>   ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
>   eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
>   command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/eudc-tests.el" "
>   command-line()
>   normal-top-level()
> Test eudcb-ldap condition:
>     (error "No match")
>    FAILED  10/11  eudcb-ldap (1.024022 sec) at lisp/net/eudc-tests.el:271
> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc...
> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc... done
>    passed  11/11  eudcb-mailabbrev (0.002174 sec)
>
> Ran 11 tests, 9 results as expected, 1 unexpected, 1 skipped (2022-11-21 16:04:41-0800, 1.151547 sec)
>
> 1 unexpected results:
>    FAILED  eudcb-ldap
>
> 1 skipped results:
>   SKIPPED  eudcb-bbdb

Thanks for trying.

Can you try changing "(sleep-for 1)" to "(sleep-for 5)"?  (In a
subsequent patch I'll replace the sleep with a retry loop to make this
more reliable.)

If that doesn't work, then below is roughly what the test is doing.  Can
you see if this works for you on the command line?  You can change "-d
0" => "-d 255" for lots of debugging output.

The test first changes to the "test/lisp/net" directory, which is
important, because the slapd.conf line "directory eudc-resources"
specifies a relative directory.

cd test/lisp/net
/usr/sbin/slapd -h "ldap://127.0.0.1:3899" \
    -d 0 -4 \
    -f eudc-resources/slapd.conf & \
sleep 5 && \
ldapsearch -x -LLL -h127.0.0.1:3899 \
    -b "dc=gnu,dc=org" "cn=emacs-ert-test-1"
=>
dn: cn=emacs-ert-test-1,dc=gnu,dc=org
objectClass: OpenLDAPperson
cn: emacs-ert-test-1
description:: RW1hY3Mg
uid: 1
sn: ERT1
givenName: Emacs
mail: emacs-ert-test-1@ldap.gnu.org

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-22 15:21             ` Thomas Fitzsimmons
@ 2022-11-24  7:24               ` Thomas Fitzsimmons
  2022-11-24 22:09                 ` Eric Abrahamsen
  0 siblings, 1 reply; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-24  7:24 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>>
>> [...]
>>
>>> That's the extent of my email completion setup.  I think the only reason
>>> this setup doesn't generalize (assuming an EUDC EBDB backend in your
>>> case) is that other people like different UIs, e.g., when the same
>>> prefix expands to multiple possible addresses (as you alluded to), what
>>> UI should one use to select?  I use the UI provided by EUDC.
>>>
>>> Anyway, tonight I did manage to add ERT tests for the EUDC LDAP backend.
>>> Can you try:
>>>
>>> make -C test lisp/net/eudc-tests.log
>>
>> No love!
>>
>> Running 11 tests (2022-11-21 16:04:40-0800, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>>    passed   1/11  eudc--plist-member (0.000396 sec)
>>    passed   2/11  eudc-lax-plist-get (0.000433 sec)
>>    passed   3/11  eudc-plist-get (0.000417 sec)
>>    passed   4/11  eudc-plist-member (0.000390 sec)
>>    passed   5/11  eudc-test-make-address (0.000151 sec)
>>    passed   6/11  eudc-test-rfc5322-quote-phrase (0.000067 sec)
>>    passed   7/11  eudc-test-rfc5322-valid-comment-p (0.000760 sec)
>>   skipped   8/11  eudcb-bbdb (0.000102 sec)
>>    passed   9/11  eudcb-ecomplete (0.007451 sec)
>> Loading eudcb-ldap...
>> Parsing results...
>> Parsing results... done
>> Parsing results...
>> Parsing results... done
>> Test eudcb-ldap backtrace:
>>   signal(error ("No match"))
>>   apply(signal (error ("No match")))
>>   (setq value-640 (apply fn-638 args-639))
>>   (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq form-
>>   (if (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq f
>>   (let (form-description-642) (if (unwind-protect (setq value-640 (app
>>   (let ((value-640 'ert-form-evaluation-aborted-641)) (let (form-descr
>>   (let* ((fn-638 #'equal) (args-639 (condition-case err (let ((signal-
>>   (let ((ldap-process (start-process "slapd" "*slapd*" "/usr/sbin/slap
>>   (closure (t) nil (let ((value-636 (gensym "ert-form-evaluation-abort
>>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>>   ert-run-test(#s(ert-test :name eudcb-ldap :documentation "Test the L
>>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>>   ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
>>   ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
>>   ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
>>   eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
>>   command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/eudc-tests.el" "
>>   command-line()
>>   normal-top-level()
>> Test eudcb-ldap condition:
>>     (error "No match")
>>    FAILED  10/11  eudcb-ldap (1.024022 sec) at lisp/net/eudc-tests.el:271
>> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc...
>> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc... done
>>    passed  11/11  eudcb-mailabbrev (0.002174 sec)
>>
>> Ran 11 tests, 9 results as expected, 1 unexpected, 1 skipped (2022-11-21 16:04:41-0800, 1.151547 sec)
>>
>> 1 unexpected results:
>>    FAILED  eudcb-ldap
>>
>> 1 skipped results:
>>   SKIPPED  eudcb-bbdb
>
> Thanks for trying.
>
> 
[...]

>  (In a subsequent patch I'll replace the sleep with a retry loop to
> make this more reliable.)

I pushed this patch to the master branch.  When you get a chance, can
you retry:

make -C test lisp/net/eudc-tests.log

and see if it succeeds for you now?

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-22  0:15           ` Eric Abrahamsen
  2022-11-22 15:21             ` Thomas Fitzsimmons
@ 2022-11-24  9:53             ` Thomas Fitzsimmons
  1 sibling, 0 replies; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-11-24  9:53 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Alexander Adolf, 59314

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

[...]

>> Once I have that, I'll be able to extract all the configuration
>> resources (like .mailrc, ecompleterc, etc.) into a tarball.  Then we can
>> use that tarball to debug/redesign out-of-the-box completion scenarios,
>> starting from "emacs -Q + tarball", "emacs -Q + EBDB + tarball",
>> "emacs -Q + BBDB + tarball", etc.
>>
>> Without starting from "emacs -Q", it's impossible for me to know what I
>> might break in other people's configurations, when making changes to
>> message-mode's default completion code.
>
> I've already said this, but I don't think we should be pushing things in
> a direction that relies any external package or its particular behavior.
> The capf machinery should be enough, and that's very clearly defined.

I haven't figured out how the defaults are supposed to work for EUDC,
despite a bunch of attempts.  I'll keep at it, but wanted to post
status.

Here's a recipe to replicate what I'm trying:

cd test/lisp/net
/usr/sbin/slapd -h "ldap://127.0.0.1:3899" -d 0 -4 \
    -f eudc-resources/slapd.conf &

mkdir test-home
cat >test-home/.emacs <<EOF
(setq ldap-host-parameters-alist '(("ldap://localhost:3899"
                                    base "dc=gnu,dc=org" auth simple)))
(setq eudc-server-hotlist '(("ldap://localhost:3899" . ldap)))
(setq eudc-ignore-options-file t)
EOF
HOME=test-home ../../../src/emacs

C-x m emacs-ertTAB

There seem to have been many attempts in the code to get that to work by
default, but currently all the various approaches fail.  The result is
that three spaces are added to the buffer after "emacs-ert".

If instead of pressing TAB, one invokes M-x eudc-expand-try-all RET, the
EUDC multiple results UI is presented, and the completion one selects is
correctly inserted.  (This proves that message machinery is failing even
though EUDC and LDAP work.)

I've been hacking around the various EUDC code paths in message.el
(including the (setq message-expand-name-standard-ui t) one) trying to
get something to work by default but I haven't succeeded yet.

Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-24  7:24               ` Thomas Fitzsimmons
@ 2022-11-24 22:09                 ` Eric Abrahamsen
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-11-24 22:09 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Alexander Adolf, 59314


On 11/24/22 02:24 AM, Thomas Fitzsimmons wrote:
> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>>>
>>> [...]
>>>
>>>> That's the extent of my email completion setup.  I think the only reason
>>>> this setup doesn't generalize (assuming an EUDC EBDB backend in your
>>>> case) is that other people like different UIs, e.g., when the same
>>>> prefix expands to multiple possible addresses (as you alluded to), what
>>>> UI should one use to select?  I use the UI provided by EUDC.
>>>>
>>>> Anyway, tonight I did manage to add ERT tests for the EUDC LDAP backend.
>>>> Can you try:
>>>>
>>>> make -C test lisp/net/eudc-tests.log
>>>
>>> No love!
>>>
>>> Running 11 tests (2022-11-21 16:04:40-0800, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>>>    passed   1/11  eudc--plist-member (0.000396 sec)
>>>    passed   2/11  eudc-lax-plist-get (0.000433 sec)
>>>    passed   3/11  eudc-plist-get (0.000417 sec)
>>>    passed   4/11  eudc-plist-member (0.000390 sec)
>>>    passed   5/11  eudc-test-make-address (0.000151 sec)
>>>    passed   6/11  eudc-test-rfc5322-quote-phrase (0.000067 sec)
>>>    passed   7/11  eudc-test-rfc5322-valid-comment-p (0.000760 sec)
>>>   skipped   8/11  eudcb-bbdb (0.000102 sec)
>>>    passed   9/11  eudcb-ecomplete (0.007451 sec)
>>> Loading eudcb-ldap...
>>> Parsing results...
>>> Parsing results... done
>>> Parsing results...
>>> Parsing results... done
>>> Test eudcb-ldap backtrace:
>>>   signal(error ("No match"))
>>>   apply(signal (error ("No match")))
>>>   (setq value-640 (apply fn-638 args-639))
>>>   (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq form-
>>>   (if (unwind-protect (setq value-640 (apply fn-638 args-639)) (setq f
>>>   (let (form-description-642) (if (unwind-protect (setq value-640 (app
>>>   (let ((value-640 'ert-form-evaluation-aborted-641)) (let (form-descr
>>>   (let* ((fn-638 #'equal) (args-639 (condition-case err (let ((signal-
>>>   (let ((ldap-process (start-process "slapd" "*slapd*" "/usr/sbin/slap
>>>   (closure (t) nil (let ((value-636 (gensym "ert-form-evaluation-abort
>>>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>>>   ert-run-test(#s(ert-test :name eudcb-ldap :documentation "Test the L
>>>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>>>   ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
>>>   ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
>>>   ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
>>>   eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
>>>   command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/eudc-tests.el" "
>>>   command-line()
>>>   normal-top-level()
>>> Test eudcb-ldap condition:
>>>     (error "No match")
>>>    FAILED  10/11  eudcb-ldap (1.024022 sec) at lisp/net/eudc-tests.el:271
>>> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc...
>>> Parsing /home/eric/dev/emacs/test/lisp/net/eudc-resources/mailrc... done
>>>    passed  11/11  eudcb-mailabbrev (0.002174 sec)
>>>
>>> Ran 11 tests, 9 results as expected, 1 unexpected, 1 skipped (2022-11-21 16:04:41-0800, 1.151547 sec)
>>>
>>> 1 unexpected results:
>>>    FAILED  eudcb-ldap
>>>
>>> 1 skipped results:
>>>   SKIPPED  eudcb-bbdb
>>
>> Thanks for trying.
>>
>> 
> [...]
>
>>  (In a subsequent patch I'll replace the sleep with a retry loop to
>> make this more reliable.)
>
> I pushed this patch to the master branch.  When you get a chance, can
> you retry:
>
> make -C test lisp/net/eudc-tests.log
>
> and see if it succeeds for you now?

slapd refuses to run without root permissions on my laptop for some
reason, so this will have to wait until next Monday when I'm back at my
desktop.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 19:46   ` Eric Abrahamsen
  2022-11-16 20:54     ` Thomas Fitzsimmons
  2022-11-17  3:28     ` Thomas Fitzsimmons
@ 2022-12-01 15:46     ` Alexander Adolf
  2022-12-01 16:02       ` Eric Abrahamsen
  2022-12-01 15:48     ` Alexander Adolf
  3 siblings, 1 reply; 22+ messages in thread
From: Alexander Adolf @ 2022-12-01 15:46 UTC (permalink / raw)
  To: Eric Abrahamsen, Thomas Fitzsimmons; +Cc: 59314

Hello Eric,

Apologies for chiming late into this.

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 11/16/22 14:18 PM, Thomas Fitzsimmons wrote:
>> [...]
>>> 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.
>> [...]
>> (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.

That the behaviour changes depending on the CAPF front-end (corfu in
this case) could be indicative of the completion styles [1] kicking in.
I've seen cases where my completion function did return results, but
nothing was shown in the CAPF UI because the completion styles'
"filtering" wouldn't leave any alternatives to show. Not to suggest that
this is what's actually happening, but it's one possibility.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Styles.html

Other than that, I would be interested in reproducing this at my end -
if possible - to see whether there's any corner case I missed. I seems
that the change of eudc-server-hotlist from `nil' to `(("localhost" .
ecomplete) ("localhost" . mailabbrev))` triggered this behaviour for
you. With that value, no database files for ecomplete or mailabbrev, and
all Elisp settings for ecomplete and mailabbrev at their default values,
`eudc-capf-complete` does return nil for me. What else should I be doing
to reproduce the issue?


Many thanks and cheers,

  --alexander





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-11-16 19:46   ` Eric Abrahamsen
                       ` (2 preceding siblings ...)
  2022-12-01 15:46     ` Alexander Adolf
@ 2022-12-01 15:48     ` Alexander Adolf
  2022-12-01 17:49       ` Eric Abrahamsen
  2022-12-02  2:50       ` Thomas Fitzsimmons
  3 siblings, 2 replies; 22+ messages in thread
From: Alexander Adolf @ 2022-12-01 15:48 UTC (permalink / raw)
  To: Eric Abrahamsen, Thomas Fitzsimmons; +Cc: 59314

Hello Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

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

Perhaps we can be slightly more CONstructive that this. ;-)))

I am preparing a patch to message.el which refactors
`message-completion-alist` along the lines of this:

---------------------------- Begin Quote -----------------------------
(defcustom message-completion-alist
  `((,message-newgroups-header-regexp . (:category newsgroup
                                         :fieldsep-re "\\([:,]\\|^\\)[ \t]*"
                                         :completions ,#'message-expand-group))
    (,message-email-recipient-header-regexp . (:category email
                                               :fieldsep-re "\\([:,]\\|^\\)[ \t]*"
                                               :completions ,#'eudc-capf-message-expand-name)))
  "Alist of (RE . RECIPE), defining completion contexts.
This variable controls how `message-completion-function' performs
in-buffer completion.  RECIPE is either a function (deprecated),
or a plist.

When `message-completion-function' is invoked, and point is on a
line matching one of the REs in the alist, the settings in the
corresponding RECIPE are applied.

When RECIPE is a function, it is called for completion.  RECIPE
should be a function that obeys the same rules as those of
`completion-at-point-functions'.

When RECIPE is a plist, the properties control how in-buffer
completion is performed.  The following properties are currently
defined:

:category

    The symbol defining the category in
    `completion-category-defaults' to use for completion.  Also
    see `completion-category-overrides', and `completion-styles'.

:fieldsep-re

    The regular expression to use when scanning backwards in the
    buffer.  All text between point, and any preceding text
    matching this regular expression, will be used as the prefix
    for finding completion candidates.

:completions

    The function that provides completions, and that obeys the
    same rules as those of `completion-at-point-functions'.
    In-buffer completion will be performed as if
    `completion-at-point-functions' had been set to this value."
  :version "29.1"
  :group 'message
  :type '(alist :key-type regexp
                :value-type (choice (plist)
                                    (function
                                     :tag "Completion function (deprecated)"))))
----------------------------- End Quote ------------------------------

As you can see, `eudc-capf-message-expand-name` effectively replaces
`message-expand-name` altogether:

---------------------------- Begin Quote -----------------------------
(make-obsolete 'message-expand-name 'eudc-capf-message-expand-name
               "29.1")
----------------------------- End Quote ------------------------------

The patch goes on to remove everything relating to ecomplete,
mailabbrev, bbdb, and the likes from message.el, too. Get rid of all the
burritos, except one. The one and only source for email addresses in
message.el IMHO should be EUDC, and the one and only completion UI
should be whatever CAPF uses. Any and all sources for email addresses
should implement back-ends for EUDC, so they can be queried via EUDC,
which does the aggregation of results from the different sources, and
delivers it back to message.el as one lump.


EUDC backends:   ldap   ecomplete   mailabbrev   bbdb    you-name-it
               \________________________ ____________________________/
                                        V
                                        |
                                        V
eudc-capf.el:            eudc-capf-message-expand-name
                                        |
                                        V
message.el:               message-completion-function
                                        |
                                        V
minibuffer.el                completion-at-point
                                        |
                                        V
                   [ optional completion UI (for example corfu) ]


As you may imagine, this is a bigger patch, and I am discussing it on
emacs-devel with Stefan Monnier. So it'll still be a little while until
it might hopefully get merged, and the burritos unwrapped.


Many thanks and looking forward to your thoughts,

  --alexander





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-01 15:46     ` Alexander Adolf
@ 2022-12-01 16:02       ` Eric Abrahamsen
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-12-01 16:02 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Thomas Fitzsimmons, 59314

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> Hello Eric,
>
> Apologies for chiming late into this.
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On 11/16/22 14:18 PM, Thomas Fitzsimmons wrote:
>>> [...]
>>>> 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.
>>> [...]
>>> (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.
>
> That the behaviour changes depending on the CAPF front-end (corfu in
> this case) could be indicative of the completion styles [1] kicking in.
> I've seen cases where my completion function did return results, but
> nothing was shown in the CAPF UI because the completion styles'
> "filtering" wouldn't leave any alternatives to show. Not to suggest that
> this is what's actually happening, but it's one possibility.
>
> [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Styles.html
>
> Other than that, I would be interested in reproducing this at my end -
> if possible - to see whether there's any corner case I missed. I seems
> that the change of eudc-server-hotlist from `nil' to `(("localhost" .
> ecomplete) ("localhost" . mailabbrev))` triggered this behaviour for
> you. With that value, no database files for ecomplete or mailabbrev, and
> all Elisp settings for ecomplete and mailabbrev at their default values,
> `eudc-capf-complete` does return nil for me. What else should I be doing
> to reproduce the issue?

I think Thomas already fixed it! Shortly after I reported.

Thanks,
Eric





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-01 15:48     ` Alexander Adolf
@ 2022-12-01 17:49       ` Eric Abrahamsen
  2022-12-02  2:50       ` Thomas Fitzsimmons
  1 sibling, 0 replies; 22+ messages in thread
From: Eric Abrahamsen @ 2022-12-01 17:49 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Thomas Fitzsimmons, 59314

[-- Attachment #1: Type: text/plain, Size: 5888 bytes --]


On 12/01/22 16:48 PM, Alexander Adolf wrote:
> Hello Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> [...]
>> 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.
>> [...]
>> 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.
>> [...]
>
> Perhaps we can be slightly more CONstructive that this. ;-)))
>
> I am preparing a patch to message.el which refactors
> `message-completion-alist` along the lines of this:
>
> ---------------------------- Begin Quote -----------------------------
> (defcustom message-completion-alist
>   `((,message-newgroups-header-regexp . (:category newsgroup
>                                          :fieldsep-re "\\([:,]\\|^\\)[ \t]*"
>                                          :completions ,#'message-expand-group))
>     (,message-email-recipient-header-regexp . (:category email
>                                                :fieldsep-re "\\([:,]\\|^\\)[ \t]*"
>                                                :completions ,#'eudc-capf-message-expand-name)))
>   "Alist of (RE . RECIPE), defining completion contexts.
> This variable controls how `message-completion-function' performs
> in-buffer completion.  RECIPE is either a function (deprecated),
> or a plist.
>
> When `message-completion-function' is invoked, and point is on a
> line matching one of the REs in the alist, the settings in the
> corresponding RECIPE are applied.
>
> When RECIPE is a function, it is called for completion.  RECIPE
> should be a function that obeys the same rules as those of
> `completion-at-point-functions'.
>
> When RECIPE is a plist, the properties control how in-buffer
> completion is performed.  The following properties are currently
> defined:
>
> :category
>
>     The symbol defining the category in
>     `completion-category-defaults' to use for completion.  Also
>     see `completion-category-overrides', and `completion-styles'.
>
> :fieldsep-re
>
>     The regular expression to use when scanning backwards in the
>     buffer.  All text between point, and any preceding text
>     matching this regular expression, will be used as the prefix
>     for finding completion candidates.
>
> :completions
>
>     The function that provides completions, and that obeys the
>     same rules as those of `completion-at-point-functions'.
>     In-buffer completion will be performed as if
>     `completion-at-point-functions' had been set to this value."
>   :version "29.1"
>   :group 'message
>   :type '(alist :key-type regexp
>                 :value-type (choice (plist)
>                                     (function
>                                      :tag "Completion function (deprecated)"))))
> ----------------------------- End Quote ------------------------------
>
> As you can see, `eudc-capf-message-expand-name` effectively replaces
> `message-expand-name` altogether:
>
> ---------------------------- Begin Quote -----------------------------
> (make-obsolete 'message-expand-name 'eudc-capf-message-expand-name
>                "29.1")
> ----------------------------- End Quote ------------------------------
>
> The patch goes on to remove everything relating to ecomplete,
> mailabbrev, bbdb, and the likes from message.el, too. Get rid of all the
> burritos, except one. The one and only source for email addresses in
> message.el IMHO should be EUDC, and the one and only completion UI
> should be whatever CAPF uses. Any and all sources for email addresses
> should implement back-ends for EUDC, so they can be queried via EUDC,
> which does the aggregation of results from the different sources, and
> delivers it back to message.el as one lump.
>
>
> EUDC backends:   ldap   ecomplete   mailabbrev   bbdb    you-name-it
>                \________________________ ____________________________/
>                                         V
>                                         |
>                                         V
> eudc-capf.el:            eudc-capf-message-expand-name
>                                         |
>                                         V
> message.el:               message-completion-function
>                                         |
>                                         V
> minibuffer.el                completion-at-point
>                                         |
>                                         V
>                    [ optional completion UI (for example corfu) ]
>
>
> As you may imagine, this is a bigger patch, and I am discussing it on
> emacs-devel with Stefan Monnier. So it'll still be a little while until
> it might hopefully get merged, and the burritos unwrapped.
>
>
> Many thanks and looking forward to your thoughts,

My only thought is that we already have a mechanism for combining
results from multiple contact-management packages, and it's called
`message--name-table'. I don't see why we should be obliged to add EUDC
as an additional and obligatory point of collation. I'm attaching a
patch I floated earlier, showing how I think it could works -- it's very
simple.

Stefan was the one who added `message--name-table', and if you're
talking to him I will obviously defer to whatever you (plural) decide.
But that's my two cents.

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-name-databases.diff --]
[-- Type: text/x-patch, Size: 2816 bytes --]

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 3bbd68bdcd..e609aa7405 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -8266,9 +8266,11 @@ message-completion-alist
 (defcustom message-expand-name-databases
   '(bbdb eudc)
   "List of databases to try for name completion (`message-expand-name').
-Each element is a symbol and can be `bbdb' or `eudc'."
+Each element can be the symbol `bbdb', the symbol `eudc', or a function."
   :group 'message
-  :type '(set (const bbdb) (const eudc)))
+  :version "29.1"
+  :type '(repeat
+          (choice (const bbdb) (const eudc) function)))
 
 (defcustom message-tab-body-function nil
   "Function to execute when `message-tab' (TAB) is executed in the body.
@@ -8379,6 +8381,8 @@ message-expand-name
                ;; completion took place.  So let's double check the buffer was
                ;; not modified.
                (/= starttick (buffer-modified-tick)))))
+        ((and (functionp (car message-expand-name-databases))
+              (funcall (car message-expand-name-databases))))
 	(t
 	 (expand-abbrev))))
 
@@ -8408,26 +8412,28 @@ message--bbdb-query-with-words
 
 (defun message--name-table (orig-string)
   (let ((orig-words (split-string orig-string "[ \t]+"))
-        eudc-responses
-        bbdb-responses)
+        database-responses)
     (lambda (string pred action)
       (pcase action
         ('metadata '(metadata (category . email)))
         ('lambda t)
         ((or 'nil 't)
          (when orig-words
-           (when (and (memq 'eudc message-expand-name-databases)
-		      (boundp 'eudc-protocol)
-		      eudc-protocol)
-	     (setq eudc-responses (eudc-query-with-words orig-words)))
-	   (when (memq 'bbdb message-expand-name-databases)
-	     (setq bbdb-responses (message--bbdb-query-with-words orig-words)))
+           (dolist (db message-expand-name-databases)
+             (push
+              (pcase db
+                ((and `eudc (guard (bound-and-true-p eudc-protocol)))
+                 (eudc-query-with-words orig-words))
+                (`bbdb (message--bbdb-query-with-words orig-words))
+                ((pred functionp) (funcall db orig-words)))
+              database-responses))
 	   (ecomplete-setup)
 	   (setq orig-words nil))
          (let ((candidates
 	        ;; FIXME: Add `expand-abbrev'!
-	        (append (all-completions string eudc-responses pred)
-	                (all-completions string bbdb-responses pred)
+	        (append (mapcan (lambda (resp)
+                                  (all-completions string resp pred))
+                                database-responses)
 	                (when (and (bound-and-true-p ecomplete-database)
 	                           (fboundp 'ecomplete-completion-table))
                           (all-completions string

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-01 15:48     ` Alexander Adolf
  2022-12-01 17:49       ` Eric Abrahamsen
@ 2022-12-02  2:50       ` Thomas Fitzsimmons
  1 sibling, 0 replies; 22+ messages in thread
From: Thomas Fitzsimmons @ 2022-12-02  2:50 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Eric Abrahamsen, 59314

Hi Alexander,

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> Hello Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> [...]
>> 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.
>> [...]
>> 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.
>> [...]
>
> Perhaps we can be slightly more CONstructive that this. ;-)))
>
> I am preparing a patch to message.el which refactors
> `message-completion-alist` along the lines of this:

[...]

The eventual message.el refactoring could work.  But for now, for Emacs
29.1, let's focus on what's already in message.el, which is a lot!

In particular, I'm trying to make this recipe do something useful, with
a minimal patch to message.el.

1. Build Emacs master tip.

2. Install and configure BBDB:

mkdir -p test/.emacs.d
cat >test/.emacs.d/bbdb <<EOF
;; -*- mode: Emacs-Lisp; coding: utf-8; -*-
;;; file-format: 9
["Emacs" "ERT3" nil nil nil nil nil ("emacs-ert-test-3@bbdb.gnu.org") ((notes . " ")) "c8bd3a63-3a83-48a7-a95b-be118a923e00" "2022-11-19 16:36:04 +0000" "2022-11-19 16:36:04 +0000" nil]
["Emacs" "ERT4" nil nil nil nil nil ("emacs-ert-test-4@bbdb.gnu.org") ((notes . " ")) "5a93c3c5-9270-4e10-8b28-d28cfa2562cf" "2022-11-19 16:47:49 +0000" "2022-11-19 16:47:49 +0000" nil]
EOF
HOME=`pwd`/test emacs
M-x list-packages
(install BBDB from GNU ELPA)
exit Emacs

HOME=`pwd`/test emacs
C-: (eudc-set-server "localhost" 'bbdb t)
C-x m
emacs-ertTAB

When I try this, a bunch of stuff happens, then, uselessly, 3 spaces are
inserted after "emacs-ert".  During "bunch of stuff",
eudc-query-with-words is called and gets expansion results.  Why are
they not presented as possible completions?  What code is dropping them?

There is so much EUDC handling code in message.el and apparently none of
it works.  And most of this code predates the addition of
eudc-capf-complete, but its addition didn't fix this basic usage.
That's why the recommendation in the EUDC manual has always been to just
clobber "TAB" in message mode and assign eudc-expand-inline (now
eudc-expand-try-all) to it.

Before rewriting completion in message.el, before Emacs 29.1, can we
please make the logic that was there already actually work?  Please try
the above recipe; maybe I'm missing something.  If you can make it work,
let me know, or send a minimal patch to make it work.

Thanks,
Thomas





^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-12-02  2:50 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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