unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alexander Adolf <alexander.adolf@condition-alpha.com>
To: Thomas Fitzsimmons <fitzsim@fitzsim.org>
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 18:32:26 +0200	[thread overview]
Message-ID: <f116ff0a17e45b1efdb25488e4b0c362@condition-alpha.com> (raw)
In-Reply-To: <m3k0b2o5mv.fsf@fitzsim.org>

Hello Thomas,

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.

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?


Many thanks and looking forward to your thoughts,

  --alexander



  reply	other threads:[~2022-05-05 16:32 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 [this message]
2022-05-05 16:57               ` Thomas Fitzsimmons
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=f116ff0a17e45b1efdb25488e4b0c362@condition-alpha.com \
    --to=alexander.adolf@condition-alpha.com \
    --cc=emacs-devel@gnu.org \
    --cc=fgunbin@fastmail.fm \
    --cc=fitzsim@fitzsim.org \
    /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).