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:58:13 +0200 Message-ID: <72cd181d4397e8f1367a60b257320692@condition-alpha.com> 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="1496"; 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 16:07:08 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 1oEtJ6-00006K-6W for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 16:07:08 +0200 Original-Received: from localhost ([::1]:37408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEtJ5-0002tx-4V for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 10:07:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEtAa-00032e-2f for emacs-devel@gnu.org; Fri, 22 Jul 2022 09:58:20 -0400 Original-Received: from smtprelay03.ispgateway.de ([80.67.31.37]:40877) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEtAX-0004n8-NU for emacs-devel@gnu.org; Fri, 22 Jul 2022 09:58:19 -0400 Original-Received: from [46.244.207.124] (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 1oEtAr-0004SX-SC; Fri, 22 Jul 2022 15:58:37 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.31.37; 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_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:292437 Archived-At: It's too hot to think today. I deserve to correct myself in two points. Alexander Adolf writes: > [...] 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. Nope. Instead of eudc-query-with-words, the call would go to eudc-capf-message-expand-name from eudc-capf.el, of course. I'd add two new, optional parameters BEG and END to eudc-capf-message-expand-name, so the prefix bounds can be passed down from message.el. > 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. > [...] That doesn't seem quite right either. Unless we're trying to plug a new message.el into an old set of lisp, the code can simply be removed from message.el. Hope that clarifies, --alexander