From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>
Cc: Filipp Gunbin <fgunbin@fastmail.fm>, emacs-devel@gnu.org
Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode
Date: Thu, 05 May 2022 12:57:28 -0400 [thread overview]
Message-ID: <m3czgrlxxj.fsf@fitzsim.org> (raw)
In-Reply-To: <f116ff0a17e45b1efdb25488e4b0c362@condition-alpha.com> (Alexander Adolf's message of "Thu, 05 May 2022 18:32:26 +0200")
Hi Alexander,
Alexander Adolf <alexander.adolf@condition-alpha.com> writes:
> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>>> What is your value of the variable completion-auto-help?
>>
>> It is t.
>
> Ok, so that's not the reason for you having to TAB through the
> alternatives, instead of being offered the "*Completions*" buffer.
>
>>> Dies changing the value of the variable message-expand-name-standard-ui
>>> change anything for you?
>>
>> It is currently nil.
>
> Did you try with a non-nil value?
>
>> [...]
>> Can you reproduce the scenario in your screenshot, then subsequently
>> type '-' then TAB, to complete on "emacs-" instead of "emacs"; I think
>> the completion backends will be queried again. That's what I want to
>> avoid (if that doesn't happen for you, then I'll have to recreate my
>> testing environment and test more carefully with all the combinations of
>> the above variables, I guess).
>>
>> Did you confirm completion-table-with-cache is doing something? If so,
>> do you mind adding a comment within eudc-capf-message-expand-name's
>> body, describing what the caching is doing, when the cache is
>> invalidated, etc.?
>
> I have done a few experiments with this version of
> completion-table-with-cache(), sprinkled with some message printing:
>
> ---------------------------- Begin Quote -----------------------------
> (defun completion-table-with-cache (fun &optional ignore-case)
> (let* (last-arg last-result
> (new-fun
> (lambda (arg)
> (if (and last-arg (string-prefix-p last-arg arg ignore-case))
> (prog1
> last-result
> (message "[cache HIT] arg = [%s]" arg))
> (prog1
> (setq last-result (funcall fun arg))
> (message "[cache miss] arg = [%s]" arg)
> (setq last-arg arg))))))
> (completion-table-dynamic new-fun)))
> ----------------------------- End Quote ------------------------------
>
>
> Experiment #1: 3rd Party UI Package
> ===================================
>
> [1] https://github.com/minad/corfu
>
> Using the corfu package [1], I get the following output in the messages
> buffer for your use-case:
>
> --------------------------- Begin Transcript -------------------------
> <<< typing "emacs"
>
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
> eudc-query-with-words
> [cache miss] arg = []
> [cache HIT] arg = [emacs]
>
> <<< typing "-"
>
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
> [cache HIT] arg = []
> [cache HIT] arg = [emacs-]
> ---------------------------- End Transcript --------------------------
>
> On the first message "eudc-capf-complete", I type "emacs", and on the
> second, I type "-" as you describe.
>
> I.e. eudc-query-with-words gets called once only, whereas the capf
> function gets called every time. The caching works as expected for me.
>
>
> Experiment #2: message-tab
> ==========================
>
> Similar workflow as before, but instead of the 3rd party package,
> invoking message-tab:
>
> --------------------------- Begin Transcript -------------------------
> <<< typing "emacs"
> <<< invoking message-tab
>
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
> eudc-query-with-words
> [cache miss] arg = []
> [cache HIT] arg = [emacs]
> Making completion list...
> [cache HIT] arg = []
> nil
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
>
> <<< typing "-"
>
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
>
> <<< invoking message-tab
>
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
> eudc-query-with-words
> [cache miss] arg = []
> [cache HIT] arg = [emacs-]
> Making completion list...
> [cache HIT] arg = []
> nil
> eudc-capf-complete --------------------------------------
> eudc-capf-message-expand-name
> ---------------------------- End Transcript --------------------------
>
> As you observed, too, eudc-query-with-words is invoked every time.
>
>
> Experiment #3: completion-at-point
> ==================================
>
> Same as #2 above, but instead of message-tab, this time invoking
> completion-at-point.
>
> The result is almost identical to #2, too, with the difference that
> instead of the nil near the end of the end of the bigger message blocks,
> it now shows a t. Not sure where this nil/t output comes from anyway?
>
>
> Conclusions
> ===========
>
> How completion-at-point is wrapped makes a significant difference. With
> the vanilla front-end(s) in message mode, the CAPF function gets invoked
> many more times than with the 3rd party package. This also seems to
> affect to what extent the cache can be taken advantage of by
> completion-at-point.
This is good analysis, thanks for writing it up. Interesting that corfu
seems to be more efficient than the built-in front-ends. For this use
case, it seems to me that the built-in front-ends should continue
narrowing down from what's in the cache, since no new completions will
come from the backends if the search string only gets more specific.
> Given that the behaviour appears linked to message.el, what could seem a
> useful way forward? Perhaps this is something for the maintainer of
> message.el to look into? A view from someone familiar with the details
> of completion-at-point might also be helpful?
Yes; in particular, it would be nice to have an overview node in the
manual about how everything CAPF-related is supposed to fit together,
for mode authors who want to "complete this type of thing", for
completion UI authors who want to show a list of choices in some way,
and for completion backend authors who want to provide lists to
requesters.
In any case, I think your patch is an improvement to the default
message.el behaviour, and I don't necessarily want to hold it up waiting
for built-in CAPF front-end redesigns. Let's give it another day and if
we haven't figured out this design/optimization issue by then, I'll push
what you've provided so far, as a work-in-progress.
Thomas
next prev parent reply other threads:[~2022-05-05 16:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-09 16:24 [PATCH] EUDC email addresses via completion-at-point in message-mode Alexander Adolf
2022-04-12 21:12 ` Thomas Fitzsimmons
2022-04-13 14:44 ` Alexander Adolf
2022-04-14 0:26 ` Thomas Fitzsimmons
2022-04-15 21:23 ` Alexander Adolf
2022-04-14 13:02 ` Eric S Fraga
2022-04-14 13:27 ` Thomas Fitzsimmons
2022-04-14 13:52 ` Eric S Fraga
2022-04-15 21:39 ` Alexander Adolf
2022-04-17 12:12 ` Eric S Fraga
2022-04-15 21:35 ` Alexander Adolf
2022-04-17 12:20 ` Eric S Fraga
2022-04-17 13:58 ` Thomas Fitzsimmons
2022-04-17 17:21 ` Eric S Fraga
2022-04-14 14:02 ` Stefan Monnier
2022-04-15 21:58 ` Alexander Adolf
2022-04-15 22:57 ` Eric Abrahamsen
2022-04-14 1:44 ` Eric Abrahamsen
2022-04-14 13:04 ` Eric S Fraga
2022-04-14 15:17 ` Eric Abrahamsen
2022-04-14 15:26 ` Stefan Monnier
2022-04-15 16:31 ` Eric Abrahamsen
2022-04-15 17:17 ` Stefan Monnier
2022-04-15 22:30 ` Alexander Adolf
2022-04-15 22:16 ` Alexander Adolf
2022-04-15 22:58 ` Stefan Monnier
2022-04-26 14:39 ` Alexander Adolf
2022-04-26 18:58 ` Filipp Gunbin
2022-04-28 17:15 ` Alexander Adolf
2022-04-29 14:43 ` Thomas Fitzsimmons
2022-05-02 17:10 ` Alexander Adolf
2022-05-03 18:03 ` Thomas Fitzsimmons
2022-05-05 16:32 ` Alexander Adolf
2022-05-05 16:57 ` Thomas Fitzsimmons [this message]
2022-05-10 21:16 ` Thomas Fitzsimmons
2022-05-16 12:35 ` Alexander Adolf
2022-04-29 23:04 ` Filipp Gunbin
2022-05-02 21:38 ` Alexander Adolf
2022-05-02 22:32 ` Filipp Gunbin
2022-05-03 16:18 ` Alexander Adolf
2022-05-03 16:22 ` Alexander Adolf
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3czgrlxxj.fsf@fitzsim.org \
--to=fitzsim@fitzsim.org \
--cc=alexander.adolf@condition-alpha.com \
--cc=emacs-devel@gnu.org \
--cc=fgunbin@fastmail.fm \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).