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: Fri, 15 Apr 2022 23:23:28 +0200 Message-ID: <61482bcaa1c337ba55f6268fbc313100@condition-alpha.com> 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="28881"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Thomas Fitzsimmons Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 15 23:24:14 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 1nfTQL-0007I8-Pw for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 23:24:13 +0200 Original-Received: from localhost ([::1]:43822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfTQK-0000yC-7K for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 17:24:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfTPk-0000Ir-2k for emacs-devel@gnu.org; Fri, 15 Apr 2022 17:23:36 -0400 Original-Received: from smtprelay07.ispgateway.de ([134.119.228.103]:6235) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfTPi-0001Bk-2U for emacs-devel@gnu.org; Fri, 15 Apr 2022 17:23:35 -0400 Original-Received: from [46.244.203.213] (helo=condition-alpha.com) by smtprelay07.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nfTPk-000571-Mb; Fri, 15 Apr 2022 23:23:36 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.103; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay07.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, 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:288462 Archived-At: Hello Thomas, Thomas Fitzsimmons writes: > [...] > It looks like the default binding for TAB in message-mode-map is > message-tab; so I tested by rebinding TAB to message-tab. It worked, > except I was expecting case sensitive results. Can you please change > `completion-ignore-case' to nil? And figure out what to do with > `completion-table-with-cache''s IGNORE-CASE argument accordingly, if > necessary? Ah, well spotted! Thanks for noticing; consider it fixed. "Thou shalt not impose your will on users more than necessary." ;-) I have simply removed completion-ignore-case from the setq-local call, as it shouldn't have been there (probably a left-over from the first attempts when I was still trying to force things). The IGNORE-CASE argument to completion-table-with-cache should stay at t, as it signals whether the function being called (eudc-query-with-words) is case sensitive (it is not). > I had to run (message-tab) repeatedly to get the final result if > multiple results were available, whereas with eudc-expand-try-all bound > to TAB, I get a "Multiple matches found; choose one:" prompt. I guess > that's just a different UI style for completion-at-point? FWIW, I think > I prefer eudc-expand-try-all's behaviour. Does changing the value of the variable message-expand-name-standard-ui change anything for you? There are a couple of completion-specific variables changing the behaviour [1], and 3rd party packages might have an effect, too. [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Options.html That said, the patch leaves it entirely to the user to configure the user interface and its behaviour. > I have one bbdb entry and one LDAP server in the hotlist. It seems like > the LDAP operation happens every time I call (message-tab). Is that > expected? Yes. > Is the completion table caching meant to prevent this? Yes. > I don't like the idea that hitting TAB several times per email address > will result in several calls to the LDAP server. Can > completion-at-point be made to have the same behaviour as > eudc-expand-try-all, which only results in each backend being queried > once? > [...] That's what I had hoped would be the result of using the function completion-table-with-cache. From the docstring: "...saves the last argument-result pair from FUN, so that several lookups with the same argument (or with an argument that starts with the first one) only need to call FUN once." The thing is, I cannot control how many times the function completion-at-point calls functions on completion-at-point-functions, nor how often completion-at-point is called itself, which is determined by the user-interface on top of completion-at-point. If anyone gas further insight, any hints are highly appreciated. --alexander