[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59314: 29.0.50; EUDC and message-mode header completion
From: |
Thomas Fitzsimmons |
Subject: |
bug#59314: 29.0.50; EUDC and message-mode header completion |
Date: |
Tue, 06 Dec 2022 22:14:10 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/01
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/01
- bug#59314: 29.0.50; EUDC and message-mode header completion, Eric Abrahamsen, 2022/12/01
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/01
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/06
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/06
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/06
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/06
- bug#59314: 29.0.50; EUDC and message-mode header completion,
Thomas Fitzsimmons <=
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/07
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/07
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/08
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/08
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/09
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/10
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/12
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/13
- bug#59314: 29.0.50; EUDC and message-mode header completion, Alexander Adolf, 2022/12/14
- bug#59314: 29.0.50; EUDC and message-mode header completion, Thomas Fitzsimmons, 2022/12/14