From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode Date: Thu, 05 May 2022 18:32:26 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40576"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Filipp Gunbin , emacs-devel@gnu.org To: Thomas Fitzsimmons Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 05 18:58:34 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nmeoE-000ALS-3H for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 18:58:34 +0200 Original-Received: from localhost ([::1]:39198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmeoA-0006hR-Oa for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 12:58:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmeP5-0001Qs-9t for emacs-devel@gnu.org; Thu, 05 May 2022 12:32:35 -0400 Original-Received: from smtprelay03.ispgateway.de ([80.67.18.15]:42998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmeP3-0001EW-9u for emacs-devel@gnu.org; Thu, 05 May 2022 12:32:34 -0400 Original-Received: from [46.244.195.3] (helo=condition-alpha.com) by smtprelay03.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nmeP6-0000vR-Gw; Thu, 05 May 2022 18:32:36 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.18.15; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay03.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289252 Archived-At: Hello Thomas, Thomas Fitzsimmons 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