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: master 620ac67355: EUDC: Add completion-at-point support Date: Mon, 16 May 2022 15:12:18 +0200 Message-ID: <2a2c01266911f1452ced1cb918af92eb@condition-alpha.com> References: <165221712797.22071.2062685793306083928@vcs2.savannah.gnu.org> <20220510211208.6A954C01683@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23826"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 16 15:14:51 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 1nqaYl-0005zT-6u for ged-emacs-devel@m.gmane-mx.org; Mon, 16 May 2022 15:14:51 +0200 Original-Received: from localhost ([::1]:35422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nqaYj-0004j3-Tj for ged-emacs-devel@m.gmane-mx.org; Mon, 16 May 2022 09:14:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqaWO-0002bW-AE for emacs-devel@gnu.org; Mon, 16 May 2022 09:12:24 -0400 Original-Received: from smtprelay02.ispgateway.de ([80.67.18.44]:8661) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqaWM-00087c-CR for emacs-devel@gnu.org; Mon, 16 May 2022 09:12:24 -0400 Original-Received: from [46.244.204.159] (helo=condition-alpha.com) by smtprelay02.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nqaWH-0006qO-1O; Mon, 16 May 2022 15:12:17 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.18.44; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay02.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_H3=0.001, RCVD_IN_MSPIKE_WL=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:289805 Archived-At: Hello Stefan, Stefan Monnier writes: > [...] > Could you contrast the behavior of this new code with the one we get > from `message--name-table` (i.e. when setting > `message-expand-name-standard-ui`)? > > Looking at the code in message.el it seems it should provide a fairly > similar behavior. It seems to do similar caching, uses > (eudc-query-with-words (split-string orig-string "[ \t]+")) like your > code, tho your code passes an extra t arg to "try-all-servers". > Maybe message.el should also use that? > [...] Thanks for your comments. I think there are (at least) two angles from which we can look at this. The first angle is the query semantics, and the "breadth and quality" of search results, as you appear to be referring to. Under this angle, I concur with your assessment that the improvements to the "breadth and quality" of search results could probably have been retro-fitted onto the existing code in message.el just as well. The second angle is how and where the functionality is embedded in the wider structure of the code, and, as a consequence of this, what use cases that enables. I think that it is under this second angle that my patch provides the most advantages; at least that was my intention. As you mention (message-expand-name-standard-ui), message.el sees itself as being "in charge" of the completion UI, and I'll need to carefully configure it to "stay away" from handling the completion UI to allow me to use one of my liking. In fact I was when I started moving my setup to use the corfu package [1] as my completion UI, when I cam eto the conclusion that this patch would be needed to achieve my goal. [1] https://github.com/minad/corfu Looking beyond this (really sticking my head out the window even further now), this patch gives us the option of moving "everything email addresses" into EUDC. The next thing I'll spend some time on are EUDC back-ends for ecomplete and mailabbrev. EUDC has a bbdb back-end already. With that, all code that deals with the different sources for email addresses could move from message.el to EUDC. In such a scenario, message.el would need to do the marshalling between the different completion contexts (email, newsgroup, subject, body, etc.) only. All other special handling for email address completion that is there today, would no longer be needed in message.el. Hoping to have helped, and looking forward to your thoughts, --alexander