all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, 59314@debbugs.gnu.org
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Tue, 13 Dec 2022 20:34:00 -0500	[thread overview]
Message-ID: <m3edt27oqf.fsf@fitzsim.org> (raw)
In-Reply-To: <7e3a877bcb178da3a5a4be518c7567f1@condition-alpha.com> (Alexander Adolf's message of "Mon, 12 Dec 2022 23:10:39 +0100")

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

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>> The scenario I'd like you to make work with a minimal patch is:
>> Scenario 3+1 + (setq message-expand-name-standard-ui t).
>>
>> Did you try that? 
>
> Yes.
>
>> I'm pretty sure if you get that working you'll find that we don't need
>> eudc-capf-complete in completion-at-point-functions (yet), since what
>> was there will already do what eudc-capf-complete was trying to
>> achieve.
>>
>> Basically, this whole part of the discussion I've been thinking in terms
>> of "(setq message-expand-name-standard-ui t)".
>>
>> When message-expand-name-standard-ui is nil, I think we've determined
>> that eudc-capf-complete's presence in completion-at-point-functions
>> breaks EUDC functionality.  Do you concur?
>
> Yes.
>
>> If that's the case we should probably remove eudc-capf-complete from
>> completion-at-point-functions for Emacs 29.1, since that would
>> represent a regression.
>
> That's one option of addressing this case. The other option would be to
> apply the last patch I sent to add `(setq-local completion-styles...)`
> to `eudc-capf-complete` (because this is a defect and needs to be added
> in any case). Albeit with an updated message, because the message
> pretends to fix the bug, which it apparently doesn't.
>
> My preferred outcome would thus be:
>
> 1) Re-remove the `(add-hook 'completion-at-point-functions
> #'eudc-capf-complete ...)` line from message.el.
>
> 2) Add the `(setq-local completion-styles ...)` fix to
> `eudc-capf-complete`.
>
> 3) See if we can figure a root cause for the completion styles breakage
> within reasonable time and effort.
>
> The attached patch implements 1) and 2).
>
>> I now understand that the intent of the code that was there before we
>> added eudc-capf-complete was:
>>
>> message-expand-name-standard-ui nil => use EUDC multi-selector UI
>> message-expand-name-standard-ui t   => use completion-at-point selector UI
>>
>> But the second case was already broken before we added
>> eudc-capf-complete.
>
> Indeed.
>
> And it also broken when not using EUDC at all, as I reported in my
> last message ('eudc removed from `message-expand-name-databases`).
>
>> I want to understand and fix that case.
>> [...]
>
> My suspicion is that something about the completion styles was changed.
> Mu next step would hence be to meditate over the `git blame` of
> minibuffer.el.
>
> Looking forward to your thoughts,

I've applied your patch locally and I'm testing with it, thanks.  I'm
also setting (setq message-expand-name-standard-ui t).

This may be a clue; while I was experimenting, I found that this:

@@ -8432,7 +8438,7 @@ message--name-table
                           (all-completions string
                                            (ecomplete-completion-table 'mail)
                                            pred)))))
-	   (if action candidates (try-completion string candidates))))))))
+	   (if action (cdr candidates) (try-completion string candidates))))))))

results in the expansion working (albeit always expanding to Emacs
ERT4).  So it seems the issue is with a list of more than one candidate,
probably on the return path through the completion functions in
minibuffer.el.  I haven't been able to follow the return path all the
way yet.

Other complications:

1. If I do completion via bbdb-complete-mail first, before I've done
   (setq message-expand-name-standard-ui t), message-expand-name gets
   added to message--old-style-completion-functions dynamically,
   resulting in completion doing absolutely nothing.  If I set
   message-expand-name-standard-ui back to nil, then stock BBDB
   completion works again.  So there is a stateful interaction between
   stock BBDB completion and message-expand-name-standard-ui, where you
   have to set message--old-style-completion-functions back to nil if
   you want to change between the two.

2. When I switch to the *unsent mail* buffer, and press TAB, message-tab
   runs.  But if I then press TAB again, completion-at-point runs.  I
   have to switch out of the buffer then back in for message-tab to be
   run again.  It seems to enter a mode, with a new TAB keybinding,
   where it's trying to use completion-at-point within a region.

Thomas





  reply	other threads:[~2022-12-14  1:34 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-08 22:58                         ` Thomas Fitzsimmons
2022-12-10  1:40                           ` Alexander Adolf
2022-12-10 14:27                             ` Thomas Fitzsimmons
2022-12-12 22:10                               ` Alexander Adolf
2022-12-14  1:34                                 ` Thomas Fitzsimmons [this message]
2022-12-14 18:07                                   ` Alexander Adolf
2022-12-15  3:32                                     ` Thomas Fitzsimmons
2022-12-19 16:09                                       ` Alexander Adolf
2022-12-21 17:39                                 ` Thomas Fitzsimmons
2022-12-11 16:08                           ` Alexander Adolf
2022-12-12 12:31                             ` Thomas Fitzsimmons
2022-12-07 22:20                   ` Alexander Adolf
2023-02-11  3:30         ` Thomas Fitzsimmons
2023-01-31 13:04 ` Julien Cubizolles
2023-02-05  0:48   ` Thomas Fitzsimmons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3edt27oqf.fsf@fitzsim.org \
    --to=fitzsim@fitzsim.org \
    --cc=59314@debbugs.gnu.org \
    --cc=alexander.adolf@condition-alpha.com \
    --cc=eric@ericabrahamsen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.