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: Thoughts on Refactoring In-Buffer Completion In message.el Date: Fri, 22 Jul 2022 15:20:31 +0200 Message-ID: References: <82e662dc46347e410c0b1d871e998b00@condition-alpha.com> <5b04a4a1f5a497f030397f6813551ad2@condition-alpha.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 22 15:21:50 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 1oEsbF-0000p2-0Q for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 15:21:49 +0200 Original-Received: from localhost ([::1]:59806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEsbD-0007J9-UD for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 09:21:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEsaC-0006Dw-VH for emacs-devel@gnu.org; Fri, 22 Jul 2022 09:20:47 -0400 Original-Received: from smtprelay04.ispgateway.de ([80.67.31.38]:23047) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEsaB-0003rZ-1X for emacs-devel@gnu.org; Fri, 22 Jul 2022 09:20:44 -0400 Original-Received: from [46.244.207.124] (helo=condition-alpha.com) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oEsaI-0007oO-R4; Fri, 22 Jul 2022 15:20:51 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.31.38; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay04.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:292431 Archived-At: Stefan Monnier writes: > [...] > A "completion table" can take several shapes, one of which is > a function. > [...] That clarifies, thanks. We're on the same page. Now I _think_ I understood a little better where you seem to be heading. It appears your (as of yet not explicitly described) goal is to have a collection of message--name-table type things in message.el, and depending on the completion context plug the corresponding one of them into at (list beg end collection) construct, which is then returned by message-completion-function? One of the added values of message--name-table seems to be the marshalling of, and the merging of results from, the different completion sources (eudc, bbdb, and ecomplete; not mailabbrev though?). EUDC has recently gained the ability to do multi-server queries, and deliver the combined results from all servers, and it was hence my idea that this marshalling/merging functionality could now conveniently be outsourced from message.el to EUDC. There is a bbdb back-end for EUDC already, and I have back-ends for ecomplete and mailabbrev sitting on my hard drive. I.e. there would not be any "degradation" in terms of end-user functionality (same set of completion candidates as before), and additional sources like e.g. LDAP, and macOS Contacts would become available "for free" by calling eudc-query-with-words with its new TRY-ALL-SERVERS parameter set to t. It would seem that quite a couple of lines of code could be "commented out" of message.el under `(if (<= emacs-major-version 29) ...)` as a result of such a change. Also, message.el would no longer need to deal with any completion UI issues, and any completion UI related code in ecomplete, and mailabbrev would no longer be used. Another thing to look at would seem the "harvesting" of email addresses. Today, there is support for ecomplete in message.el. It might be just as (more?) appropriate to provide a new hook for this? Along the lines of what is now in message-put-addresses-in-ecomplete, instead of a hard-coded call to ecomplete, user-provided hook functions could be called for each header. At the end of the day, message.el would be completely independent of what databases people use, or don't use. It would interface with EUDC only, and leave "address harvesting" to user functions called from a new message send hook. Many thanks and looking forward to your thoughts, --alexander