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: Mon, 27 Jun 2022 18:37:00 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25454"; 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 Mon Jun 27 18:44: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 1o5rr1-0006Ns-3m for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 18:44:51 +0200 Original-Received: from localhost ([::1]:59788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5rqz-0000P7-VP for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 12:44:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5rjX-0006w8-7E for emacs-devel@gnu.org; Mon, 27 Jun 2022 12:37:07 -0400 Original-Received: from smtprelay07.ispgateway.de ([134.119.228.104]:12337) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5rjV-0005J3-93 for emacs-devel@gnu.org; Mon, 27 Jun 2022 12:37:06 -0400 Original-Received: from [46.244.205.209] (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 1o5rjM-0007nJ-M0; Mon, 27 Jun 2022 18:36:56 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.104; 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:291667 Archived-At: Hello Stefan, Stefan Monnier writes: >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 >> =E2=94=82 (defcustom message-completion-alist >> =E2=94=82 `((,message-newgroups-header-regexp >> =E2=94=82 . '(:capf-style 'newsgroup >> =E2=94=82 :capf-funs '(gnus-capf-complete))) ;; hypothet= ical >> =E2=94=82 (,message-email-recipient-header-regexp >> =E2=94=82 . '(:capf-style 'email >> =E2=94=82 :capf-funs '(eudc-capf-complete)))) ;; exists >> =E2=94=82 "docstring" >> =E2=94=82 ) >> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > > Sounds fine, tho "capf-style" sounds wrong: these are the names of > categories, not a styles. These names were just for illustration, so happy to use better fitting names. Perhaps `completion-style-category`? A shorter version? > Also `capf-funs` sounds wrong: [...] They are either tables, or functions that return tables. As of today, the entries in message-completion-alist are functions. > Currently we have `message-completion-alist` which decides on > a line-by-line basis what kind of completion we're doing, and then we > have a specialized function that decides what's the BEG..END to use and > which backend to use. > > Maybe `message-completion-alist` should be beefed up so that it cuts > this middle man (specialized function): i.e. provide not just > a line-based regexp to decide which specialized function to use, but > also provide some way to specify the BEG..END and the backend*S*. Good point, and agreed that determining (beg . end) should also be done in message.Eli. > Maybe have it be a list of (FUNCTION CATEGORY . BACKENDS) ? > where FUNCTION should return (BEG . END) if this completion applies? In some situations this will be called for every keystroke. Would the extra overhead of a function call seem acceptable for this? OTOH, the code of each of those functions would probably look extremely similar. The format of header lines where specific completion is to be attempted always seems to be: header-label ':' record | record-list (I'm thinking of To/Cc/etc. and Newsgroups/Followup-To/etc.) Thus, the only parameters for such functions would seem to be a regular expression to match the header-label, and the character (or regex?) that is used as the record separator. So we might just as well put the header-label regex, and the record separator char in `message-completion-alist`? >> 2) Refactor ecomplete, mailabbrev, and bbdb stuff out of message.el as >> much as possible. > > AFAIK this is already done for `ecomplete`. > [...] Searching for `ecomplete` in message.el (tip of master as of this writing): message.el 1390:The default is `abbrev', which uses mailabbrev. `ecomplete' uses 1396: (const :tag "Use ecomplete" ecomplete) 1400: "List of `self-insert-command's used to trigger ecomplete. 1402:header, ecomplete will suggest the candidates of recipients (see also 1937:(defvar message-inhibit-ecomplete nil) 3097: (when (and (message-mail-alias-type-p 'ecomplete) 3181: ((message-mail-alias-type-p 'ecomplete) 3182: (ecomplete-setup))) 4445: ;; Do ecomplete address snarfing. 4446: (when (and (message-mail-alias-type-p 'ecomplete) 4447: (not message-inhibit-ecomplete)) 4448: (message-put-addresses-in-ecomplete)) 8021: (message-inhibit-ecomplete t) 8344:`ecomplete', `message-self-insert-commands' should probably be 8414: (ecomplete-setup) 8420: (when (and (bound-and-true-p ecomplete-database) 8421: (fboundp 'ecomplete-completion-table)) 8423: (ecomplete-completion-table= 'mail) 8628:(declare-function ecomplete-add-item "ecomplete" (type key text)) 8629:(declare-function ecomplete-save "ecomplete" ()) 8631:(defun message-put-addresses-in-ecomplete () 8632: (require 'ecomplete) 8640: (ecomplete-add-item 'mail (car (mail-header-parse-address string)) 8642: (ecomplete-save)) 8644:(autoload 'ecomplete-display-matches "ecomplete") 8666: (ecomplete-display-matches 'mail word choose)))) 8671:(defun message-ecomplete-capf () 8674: (when (and (bound-and-true-p ecomplete-database) 8675: (fboundp 'ecomplete-completion-table) 8683: `(,start ,end ,(ecomplete-completion-table 'mail))))) That's 40 hits, and looking at the matching lines, my first impression would not frankly be that ecomplete integration has been reduced to a bare minimum. Looking forward to your thoughts, --alexander