From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode Date: Thu, 05 May 2022 12:57:28 -0400 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="38373"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Filipp Gunbin , emacs-devel@gnu.org To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 05 19:06:02 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 1nmevR-0009iC-VB for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 19:06:02 +0200 Original-Received: from localhost ([::1]:51870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmevQ-0007TN-KO for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 13:06:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmenM-0006qg-4t for emacs-devel@gnu.org; Thu, 05 May 2022 12:57:41 -0400 Original-Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]:34344) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmenJ-0007Im-9S for emacs-devel@gnu.org; Thu, 05 May 2022 12:57:39 -0400 Original-Received: by mail-il1-x129.google.com with SMTP id i22so3237688ila.1 for ; Thu, 05 May 2022 09:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=vIPaAF4xFrWk/R92ud7GL8nJTg97ImcRm+H0Mor8+pw=; b=2irHTSgDBNJW1M/7G2tQtwMAhsHJ4XT4ZGowbmpkOW7rLOLYuqZIullRg9G36ne14C rdUyLcslPhNeEPJq/2MUzBV88o7K4R8RTOmj+FcE9GZMSgk2QZg+T1ov4/uU2CZw6sWO /2u+gOA8w2WTgwMl2+/4/Ic9FftO7j+IPQxgLyFPf/7fjI7BC2zaItfSlUBgJoB2NoED cVIrY7CjJFFtRi2W0m+c85y5CV7F1/D//vGiKtjfiEY9vl8TqJ83Ln5XY5dkgHQICqck npmBUXJ7Aa4oXT5PIoOXZQfjAM1uyxSI9rwVnKEZO3BPzBGEbaD3jAvj5BtW87am5CPZ SIzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=vIPaAF4xFrWk/R92ud7GL8nJTg97ImcRm+H0Mor8+pw=; b=wbOMg9Io0UwC4RH5kGeZoSGFaMJHjnPJWxBsB3tCzwR0vim6dqXUBeij2TKXN+7OGK q79WejF3is3Izt6g3z218glMAGJBXBaIdJaV7JIACoXjXE9tJ6SewFSDGqjsrDSaQjDf PfYqgYutKCiNN/TQ8Ochn73BS79F4xZfIv/OTgLC1WaawZwXcJqaKqn1CLE9OxW5Glyb vVPKTk6Y/KxJN/WrqBCXHgnQvvAX36emDZMkBHQRy1rnLlfReVwg7kkaIJuEDm7+VINc eK+cJMOjl0OTuHByRrmlEaotOtCuczIUAX40SctMDKxR5P2Qv+tg+wAzNnLnrBbtVTb7 +XYg== X-Gm-Message-State: AOAM530DnRVBwvwsSw9XNwuIxG8BcaYgIftv64N1CVMPRghWSOTl1Qea qgwz6NUctB9kHikmfUhigzvH60yve4quZNqB X-Google-Smtp-Source: ABdhPJxyaumBIkZYqa5leuNfo1ZNXiRvzwFmgxg4eHLWEmaqaoDILH7sf/9+wZUUsAUouNi9ddNYNg== X-Received: by 2002:a92:cd8d:0:b0:2cd:81ce:79bd with SMTP id r13-20020a92cd8d000000b002cd81ce79bdmr10257962ilb.252.1651769850958; Thu, 05 May 2022 09:57:30 -0700 (PDT) Original-Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id d4-20020a023f04000000b0032b3a7817a3sm617357jaa.103.2022.05.05.09.57.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 May 2022 09:57:29 -0700 (PDT) In-Reply-To: (Alexander Adolf's message of "Thu, 05 May 2022 18:32:26 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::129; envelope-from=fitzsim@fitzsim.org; helo=mail-il1-x129.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:289254 Archived-At: Hi Alexander, Alexander Adolf writes: > 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. 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