all messages for Emacs-related lists mirrored at yhetil.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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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
  2022-12-06 20:40         ` Alexander Adolf
  1 sibling, 1 reply; 31+ 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] 31+ messages in thread

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-02  2:50       ` Thomas Fitzsimmons
@ 2022-12-06 20:40         ` Alexander Adolf
  2022-12-06 20:52           ` Thomas Fitzsimmons
  0 siblings, 1 reply; 31+ messages in thread
From: Alexander Adolf @ 2022-12-06 20:40 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Eric Abrahamsen, 59314

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

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

Fully agree.

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

Looking at this now.

While I set this up: What's your value of the variable
`completion-styles` during this test? Does changing `completion-styles`
to '(substring partial-completion) for the test change the result and
outcome?


Cheers,

  --alexander





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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-06 20:40         ` Alexander Adolf
@ 2022-12-06 20:52           ` Thomas Fitzsimmons
  2022-12-06 23:29             ` Alexander Adolf
  0 siblings, 1 reply; 31+ messages in thread
From: Thomas Fitzsimmons @ 2022-12-06 20:52 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Eric Abrahamsen, 59314

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

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>> 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!
>
> Fully agree.
>
>> In particular, I'm trying to make this recipe do something useful, with
>> a minimal patch to message.el.
>> [...]
>
> Looking at this now.

Great, thank you.

> While I set this up: What's your value of the variable
> `completion-styles` during this test?

I didn't change it, so it should be the default, which looks to be:
(basic partial-completion emacs22)

> Does changing `completion-styles` to '(substring partial-completion)
> for the test change the result and outcome?

I'll try this later today.

Thanks,
Thomas





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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-06 20:52           ` Thomas Fitzsimmons
@ 2022-12-06 23:29             ` Alexander Adolf
  2022-12-07  1:51               ` Thomas Fitzsimmons
  0 siblings, 1 reply; 31+ messages in thread
From: Alexander Adolf @ 2022-12-06 23:29 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Eric Abrahamsen, 59314

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

>> [...]
>> Looking at this now.
>
> Great, thank you.
> [...]

With the default value of `completion-styles`, which is

     '(basic partial-completion emacs22)

I get no completion. But when setting it to

     '(substring partial-completion)

as I mentioned, I get this after calling `completion-at-point:`
----------------------------------------------------------------------
To:  <emacs-ert-test-
Subject: 
From: Alexander Adolf <alexanderadolf@laptop.fritz.box>
--text follows this line--
----------------------------------------------------------------------
Which I guess is kind of the expected result, as it inserts the longest
common prefix of the two candidates' email addresses.

I get the same result with `message-tab` (or just pressing TAB), btw.

Actually, I think the leading "<" should not be there? After appending
either "3", or "4" further completion attempts (using either function)
do not provide any results. But when I remove the leading "<", and try
to complete again (with either "3" or "4" added), I get the correct
result (for instance "Emacs ERT4 <emacs-ert-test-4@bbdb.gnu.org>").

Thus, it seems there are two things to further look into :

- set `completion-styles` to '(substring partial-completion) during the
  test

- make sure the leading "<" is not inserted when there is a partial
  match


Looking forward to your thoughts,

  --alexander





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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-06 23:29             ` Alexander Adolf
@ 2022-12-07  1:51               ` Thomas Fitzsimmons
  2022-12-07  3:14                 ` Thomas Fitzsimmons
  0 siblings, 1 reply; 31+ messages in thread
From: Thomas Fitzsimmons @ 2022-12-07  1:51 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Eric Abrahamsen, 59314

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

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>>> [...]
>>> Looking at this now.
>>
>> Great, thank you.
>> [...]
>
> With the default value of `completion-styles`, which is
>
>      '(basic partial-completion emacs22)
>
> I get no completion. But when setting it to
>
>      '(substring partial-completion)
>
> as I mentioned, I get this after calling `completion-at-point:`
> ----------------------------------------------------------------------
> To:  <emacs-ert-test-
> Subject: 
> From: Alexander Adolf <alexanderadolf@laptop.fritz.box>
> --text follows this line--
> ----------------------------------------------------------------------
> Which I guess is kind of the expected result, as it inserts the longest
> common prefix of the two candidates' email addresses.
>
> I get the same result with `message-tab` (or just pressing TAB), btw.
>
> Actually, I think the leading "<" should not be there? After appending
> either "3", or "4" further completion attempts (using either function)
> do not provide any results. But when I remove the leading "<", and try
> to complete again (with either "3" or "4" added), I get the correct
> result (for instance "Emacs ERT4 <emacs-ert-test-4@bbdb.gnu.org>").
>
> Thus, it seems there are two things to further look into :
>
> - set `completion-styles` to '(substring partial-completion) during the
>   test
>
> - make sure the leading "<" is not inserted when there is a partial
>   match

Confirmed, adding substring to completion-styles, anywhere in the list, e.g.:

(setq completion-styles '(basic substring partial-completion emacs22))

results in the behaviour you describe.  We need to make this work with
the default completion-styles setting though.

I wonder where the leading " <" comes from (a space character is also
inserted, before the '<').

Thomas





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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-07  1:51               ` Thomas Fitzsimmons
@ 2022-12-07  3:14                 ` Thomas Fitzsimmons
  2022-12-07 22:10                   ` Alexander Adolf
  2022-12-07 22:20                   ` Alexander Adolf
  0 siblings, 2 replies; 31+ messages in thread
From: Thomas Fitzsimmons @ 2022-12-07  3:14 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Eric Abrahamsen, 59314

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Alexander Adolf <alexander.adolf@condition-alpha.com> writes:
>
>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>>
>>>> [...]
>>>> Looking at this now.
>>>
>>> Great, thank you.
>>> [...]
>>
>> With the default value of `completion-styles`, which is
>>
>>      '(basic partial-completion emacs22)
>>
>> I get no completion. But when setting it to
>>
>>      '(substring partial-completion)
>>
>> as I mentioned, I get this after calling `completion-at-point:`
>> ----------------------------------------------------------------------
>> To:  <emacs-ert-test-
>> Subject: 
>> From: Alexander Adolf <alexanderadolf@laptop.fritz.box>
>> --text follows this line--
>> ----------------------------------------------------------------------
>> Which I guess is kind of the expected result, as it inserts the longest
>> common prefix of the two candidates' email addresses.
>>
>> I get the same result with `message-tab` (or just pressing TAB), btw.
>>
>> Actually, I think the leading "<" should not be there? After appending
>> either "3", or "4" further completion attempts (using either function)
>> do not provide any results. But when I remove the leading "<", and try
>> to complete again (with either "3" or "4" added), I get the correct
>> result (for instance "Emacs ERT4 <emacs-ert-test-4@bbdb.gnu.org>").
>>
>> Thus, it seems there are two things to further look into :
>>
>> - set `completion-styles` to '(substring partial-completion) during the
>>   test
>>
>> - make sure the leading "<" is not inserted when there is a partial
>>   match
>
> Confirmed, adding substring to completion-styles, anywhere in the list, e.g.:
>
> (setq completion-styles '(basic substring partial-completion emacs22))
>
> results in the behaviour you describe.  We need to make this work with
> the default completion-styles setting though.
>
> I wonder where the leading " <" comes from (a space character is also
> inserted, before the '<').

If I remove this line from message.el:

(add-hook 'completion-at-point-functions #'eudc-capf-complete -1 t)

and rebuild Emacs, then my recipe works, via:

message-tab -...-> message-expand-name -> eudc-expand-inline

The EUDC multi-selector UI is invoked allowing me to choose between
emacs-ert-test-3 and emacs-ert-test-4, and the full name and email
address is inserted correctly.  This is with completion-styles left at
its default value.

So that's one code path validated, phew.

The next one I'd like to get working is a similar recipe (again, with
eudc-capf-complete not present in message's
completion-at-point-functions):

HOME=`pwd`/test emacs
C-: (setq message-expand-name-standard-ui t)
C-: (eudc-set-server "localhost" 'bbdb t)
C-x m
emacs-ertTAB

Then I get " <emacs-ert-test-", the same as your result, in the absence
of eudc-capf-complete.  This seems to be caused by misinterpreting the
results of eudc-query-with-words.  What is 'message--name-table'
supposed to return, what is it returning, and why is its return value
producing " <..." in the output?  I could use your input on how
completion-at-point is supposed to work here.

Thank you,
Thomas





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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-07  3:14                 ` Thomas Fitzsimmons
@ 2022-12-07 22:10                   ` Alexander Adolf
  2022-12-07 22:21                     ` Thomas Fitzsimmons
  2022-12-07 22:20                   ` Alexander Adolf
  1 sibling, 1 reply; 31+ messages in thread
From: Alexander Adolf @ 2022-12-07 22:10 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Eric Abrahamsen, 59314

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

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> [...]
> If I remove this line from message.el:
>
> (add-hook 'completion-at-point-functions #'eudc-capf-complete -1 t)
>
> and rebuild Emacs, then my recipe works, via:
>
> message-tab -...-> message-expand-name -> eudc-expand-inline
>
> The EUDC multi-selector UI is invoked allowing me to choose between
> emacs-ert-test-3 and emacs-ert-test-4, and the full name and email
> address is inserted correctly.  This is with completion-styles left at
> its default value.
>
> So that's one code path validated, phew.
> [...]

There are two ends to this, I think.

For one, you are no longer adding `eudc-capf-complete` to
`completion-at-point-functions` in message mode. This seems fine given
that we are not there yet to make `eudc-capf-complete` the default thing
to happen in 29.

OTOH, `eudc-capf-complete` is now just sitting there for people to use
it. The docstring, and the NEWS entry advertise it for adding to
`completion-at-point-functions`. If & when someone does that, it won't
work as expected, as you & I just figured, because `completion-styles`
has a default value aimed at single-word replacements (such as for
programming language keywords, or prose words from a dictionary), but
not for more complex, multi-word replacements (such as email addresses).
The `substring` entry is needed for this use-case.

To make this work, I am hence attaching a patch (relative to the tip of
master as of this writing), which sets `completion-style` from
`eudc-capf-complete`. The modification is done when the user has not
modified its value (assuming that a sensible value will have been set by
the user). If you need a patch on top of the 29 branch, please don't
hesitate to drop me a note.


Hoping to have helped, and looking forward to your thoughts,

  --alexander


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Set-completion-style-for-email-addresses-when-EUDC-c.patch --]
[-- Type: text/x-patch, Size: 1639 bytes --]

From a7c5eed95321c77d4e5069a508b4b16094f4a68d Mon Sep 17 00:00:00 2001
From: Alexander Adolf <alexander.adolf@condition-alpha.com>
Date: Wed, 7 Dec 2022 23:07:11 +0100
Subject: [PATCH] Set completion-style for email addresses when EUDC
 contributes to CAPF

* lisp/net/eudc-capf.el (eudc-capf-complete): when the user has not
modified 'completion-styles', set it to a value better suited for
email address completion than the default setting (bug#59314)
---
 lisp/net/eudc-capf.el | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/lisp/net/eudc-capf.el b/lisp/net/eudc-capf.el
index e2bbd5b28b..5bd2c92441 100644
--- a/lisp/net/eudc-capf.el
+++ b/lisp/net/eudc-capf.el
@@ -104,7 +104,16 @@ eudc-capf-complete
   (if (and (seq-some #'derived-mode-p eudc-capf-modes)
            (let ((mail-abbrev-mode-regexp message-email-recipient-header-regexp))
              (mail-abbrev-in-expansion-header-p)))
-      (eudc-capf-message-expand-name)))
+      (progn
+        ;; FIXME: `completion-styles' is set to a value which seems
+        ;; better suited for email address completion if and when it
+        ;; has not been modified from it's default value (which is not
+        ;; well suited for this purpose).  This is needed until
+        ;; `message.el' will be updated to use completion categories.
+        (when (equal completion-styles
+                     (eval (car (get 'completion-styles 'standard-value))))
+          (setq-local completion-styles '(substring partial-completion)))
+        (eudc-capf-message-expand-name))))
 
 ;;;###autoload
 (defun eudc-capf-message-expand-name ()
-- 
2.38.1


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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-07  3:14                 ` Thomas Fitzsimmons
  2022-12-07 22:10                   ` Alexander Adolf
@ 2022-12-07 22:20                   ` Alexander Adolf
  1 sibling, 0 replies; 31+ messages in thread
From: Alexander Adolf @ 2022-12-07 22:20 UTC (permalink / raw)
  To: Thomas Fitzsimmons; +Cc: Eric Abrahamsen, 59314

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

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> [...]
> The next one I'd like to get working is a similar recipe (again, with
> eudc-capf-complete not present in message's
> completion-at-point-functions):
>
> HOME=`pwd`/test emacs
> C-: (setq message-expand-name-standard-ui t)
> C-: (eudc-set-server "localhost" 'bbdb t)
> C-x m
> emacs-ertTAB
>
> Then I get " <emacs-ert-test-", the same as your result, in the absence
> of eudc-capf-complete.  This seems to be caused by misinterpreting the
> results of eudc-query-with-words.  What is 'message--name-table'
> supposed to return, what is it returning, and why is its return value
> producing " <..." in the output?  I could use your input on how
> completion-at-point is supposed to work here.

I'll look into this tomorrow, and will let you know my findings.

FWIW, I'm attaching a diagram of what I _think_ `completion-at-point`
works like in general. Perhaps it will help understand how message-mode
does completion?

As you see in the diagram (and we learnt), `completion-styles` can cause
some head-scratching, since it is used to filter any candidates lists
returned by completion functions. See also [1].

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


Cheers,

  --alexander


[-- Attachment #2: Emacs CAPF.png --]
[-- Type: image/png, Size: 310464 bytes --]

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

* bug#59314: 29.0.50; EUDC and message-mode header completion
  2022-12-07 22:10                   ` Alexander Adolf
@ 2022-12-07 22:21                     ` Thomas Fitzsimmons
  2022-12-08 22:34                       ` Alexander Adolf
  0 siblings, 1 reply; 31+ messages in thread
From: Thomas Fitzsimmons @ 2022-12-07 22:21 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Eric Abrahamsen, 59314

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

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>> If I remove this line from message.el:
>>
>> (add-hook 'completion-at-point-functions #'eudc-capf-complete -1 t)
>>
>> and rebuild Emacs, then my recipe works, via:
>>
>> message-tab -...-> message-expand-name -> eudc-expand-inline
>>
>> The EUDC multi-selector UI is invoked allowing me to choose between
>> emacs-ert-test-3 and emacs-ert-test-4, and the full name and email
>> address is inserted correctly.  This is with completion-styles left at
>> its default value.
>>
>> So that's one code path validated, phew.
>> [...]
>
> There are two ends to this, I think.
>
> For one, you are no longer adding `eudc-capf-complete` to
> `completion-at-point-functions` in message mode. This seems fine given
> that we are not there yet to make `eudc-capf-complete` the default thing
> to happen in 29.

To be clear, I wasn't going to push a patch to remove that, at least not
yet.  It's not making anything worse, so might as well leave it as-is.

> [...]

I'm trying to get message--name-table's EUDC support working.  I only
wanted to remove eudc-capf-complete from the debugging equation, because
message--name-table existed way before eudc-capf-complete was
introduced.

I want to understand why it doesn't work (why it results in the " <..."
expansion).  I haven't delved deep enough into the completion-at-point
to figure that out.  I was hoping with your experience writing
eudc-capf-complete that you'd know what was wrong with
message--name-table's EUDC support.

I don't think completion-styles should have any bearing on this.
message--name-table's EUDC support has to be made to work with the
default completion-styles setting.  Do you know how to do that?

Thanks,
Thomas





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

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

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> [...]
>> For one, you are no longer adding `eudc-capf-complete` to
>> `completion-at-point-functions` in message mode. This seems fine given
>> that we are not there yet to make `eudc-capf-complete` the default thing
>> to happen in 29.
>
> To be clear, I wasn't going to push a patch to remove that, at least not
> yet.  It's not making anything worse, so might as well leave it as-is.

I see. Please kindly ignore yesterday's path then, please.

>> [...]
> I'm trying to get message--name-table's EUDC support working.  I only
> wanted to remove eudc-capf-complete from the debugging equation, because
> message--name-table existed way before eudc-capf-complete was
> introduced.
>
> I want to understand why it doesn't work (why it results in the " <..."
> expansion).  I haven't delved deep enough into the completion-at-point
> to figure that out.  I was hoping with your experience writing
> eudc-capf-complete that you'd know what was wrong with
> message--name-table's EUDC support.

I'll look into `message--name-table` and will find out what breaks with
the " <" prefix. Please allow until Friday USA time (assuming you're
there?); it's late already over here (Europe).

> I don't think completion-styles should have any bearing on this.
> message--name-table's EUDC support has to be made to work with the
> default completion-styles setting.  Do you know how to do that?

The thing is, they do have a bearing, and there is no way to avoid that.
`completion-at-point` filters the candidates returned by the
`completion-at-point-functions`, and it uses the completion style (set
by either `completion-styles`, or via a completion category signalled in
a completion table) for this.

When the completion table does not signal a completion style,
`completion-at-point` uses the value of `completion-styles` to filter
the candidates. Only matching candidates will be presented in any UI.
The default value of `completion-styles` is '(basic partial-completion
emacs22). Which - according to the manual [1] - effects the following:

---------------------------- Begin Quote -----------------------------
basic

   A matching completion alternative must have the same beginning as the
   text in the minibuffer before point. Furthermore, if there is any
   text in the minibuffer after point, the rest of the completion
   alternative must contain that text as a substring.

partial-completion

   This aggressive completion style divides the minibuffer text into
   words separated by hyphens or spaces, and completes each word
   separately. (For example, when completing command names, ‘em-l-m’
   completes to ‘emacs-lisp-mode’.)

   Furthermore, a ‘*’ in the minibuffer text is treated as a wildcard—it
   matches any string of characters at the corresponding position in the
   completion alternative.

emacs22

   This completion style is similar to basic, except that it ignores the
   text in the minibuffer after point. It is so-named because it
   corresponds to the completion behavior in Emacs 22.
----------------------------- End Quote ------------------------------
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Styles.html

I.e. the default setting of `completion-styles` will match for
candidates that have the search string at their beginning only. Example:
when the text before point is "foo", the candidates "foo", "foox", and
"foobar" will be shown, but not the candidate "barfoo".

Clearly, this is fairly useless for email address completion. Thus, the
function `message--name-table` in message.el begins like this:

---------------------------- Begin Quote -----------------------------
(defun message--name-table (orig-string)
  (let ((orig-words (split-string orig-string "[ \t]+"))
        eudc-responses
        bbdb-responses)
    (lambda (string pred action)
      (pcase action
        ('metadata '(metadata (category . email)))
[...]
----------------------------- End Quote ------------------------------

In the last quoted line, it return the list '(metadata (category .
email)) in response to the 'metadata action.

When message.el is loaded, the init code there does this:

---------------------------- Begin Quote -----------------------------
(add-to-list 'completion-category-defaults '(email (styles substring
                                                           partial-completion)))
----------------------------- End Quote ------------------------------

This defines the 'email completion category to imply the completion
styles '(substring partial-completion). Thus, whenever
`message--name-table` comes into play, these completion styles will be
in effect.

Long story, short conclusion: you can't do meaningful email address
completion with the default value of `completion styles`.


Cheers,

  --alexander





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

end of thread, other threads:[~2022-12-08 22:34 UTC | newest]

Thread overview: 31+ 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
2022-12-06 20:40         ` Alexander Adolf
2022-12-06 20:52           ` Thomas Fitzsimmons
2022-12-06 23:29             ` Alexander Adolf
2022-12-07  1:51               ` Thomas Fitzsimmons
2022-12-07  3:14                 ` Thomas Fitzsimmons
2022-12-07 22:10                   ` Alexander Adolf
2022-12-07 22:21                     ` Thomas Fitzsimmons
2022-12-08 22:34                       ` Alexander Adolf
2022-12-07 22:20                   ` Alexander Adolf

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.