From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on Refactoring In-Buffer Completion In message.el Date: Tue, 28 Jun 2022 11:49:38 -0400 Message-ID: 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="40206"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 28 17:52:31 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 1o6DVu-000AIk-NT for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 17:52:31 +0200 Original-Received: from localhost ([::1]:59320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6DVt-0001x0-MB for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 11:52:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6DTf-0006wf-06 for emacs-devel@gnu.org; Tue, 28 Jun 2022 11:50:14 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6DTX-00028k-Iw for emacs-devel@gnu.org; Tue, 28 Jun 2022 11:50:06 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3DBF1100135; Tue, 28 Jun 2022 11:49:58 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C1CD10000D; Tue, 28 Jun 2022 11:49:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1656431396; bh=uvLPJq3BwhEcX88AOcIL4E7N6yWIetiZZQ0X2bdeg6E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YTpVoe+YcL95qICRglR+wv+dKjaNBjWKpvq3Ney4OKru14G9p350/gf75I2lt+GHk NjEcjZcD7ernKhGxdcQqhs2vBg82zfmzqb4luflTwU7VFjjbx4itVJNCvbWCxAOfqT 6aMXLu+sX85xhAEV1l9716hZ8/oZkR23C/cEQEt4v9BZQLzJCHv80IizvJ1++sCXL/ 12IpAzoRNuUogo+vnvCp62bG5wL+drN+JsmgmcnAi35pSOj0HeJZkNS/xqxXEBv4cI 096i0Jps5/UUCbpBJqS2BYBuohx7f0MfWXd3Sv7A8/YCYCamXnHPPk4gymu9BIKXEs aY3A8/LKz3Hvw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F3E621204C2; Tue, 28 Jun 2022 11:49:55 -0400 (EDT) In-Reply-To: (Alexander Adolf's message of "Mon, 27 Jun 2022 18:37:00 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:291687 Archived-At: >> 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? It's not a "style category": it's more a "completion category" (it's not a classification of styles but a classification of completion candidates). To any given category the user can then associate some styles (as well as control the cycling behavior). >> Also `capf-funs` sounds wrong: [...] > They are either tables, or functions that return tables. I think they should be only completion tables (and most/all of those tables will be functions: completion tables can take the shape of lists of strings, alists, hash-tables, obarrays, or functions, but the only think we care about is that they work with the corresponding methods). That part that's wrong is not "funs" but "capf", because "capf" refers to `completion-at-point-functions` which are not completion tables but functions that return (BEG END TABLE). They're related but they're different. >> 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. Nice typo, thank you. Indeed, maybe in order to mark the enormous contribution of Eli to Emacs, maybe ELisp source files should end in `.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? An extra function call will be completely lost in the noise, yes. > 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`? You might be right, maybe we just need to add a record separator. > 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) These non-executable. > 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. Maybe I didn't express myself clearly enough: I meant that the ecomplete-based *completion* code has been clearly separated. It basically only uses `ecomplete-completion-table`. `message-ecomplete-capf` was my first attempt at doing it cleanly: it was clean alright, but it didn't allow combing this backend with another one. It's not used any more but is kept in case someone else still uses it. The place where `ecomplete` completion is used nowadays is `message--name-table` which is supposed to combine EUDC, BBDB, and Ecomplete completion tables into a single completion table. Stefan