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: [PATCH] EUDC email addresses via completion-at-point in message-mode Date: Thu, 14 Apr 2022 10:02:17 -0400 Message-ID: References: <4c3f728f989e832d224be1503808a682@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="9858"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Thomas Fitzsimmons , emacs-devel@gnu.org To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 14 16:04:34 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 1nf05K-0002Fa-Ee for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Apr 2022 16:04:34 +0200 Original-Received: from localhost ([::1]:35444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nf05J-0003aW-6V for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Apr 2022 10:04:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nf03J-0001BP-PN for emacs-devel@gnu.org; Thu, 14 Apr 2022 10:02:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47226) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nf03G-0007Nu-Kd for emacs-devel@gnu.org; Thu, 14 Apr 2022 10:02:28 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BEC671001AC; Thu, 14 Apr 2022 10:02:24 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 649CB100135; Thu, 14 Apr 2022 10:02:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649944939; bh=ygiAn+vf624ys2il3MyieBrx8Vf9j39wprDEA4O3g/Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=fvrLe2zPwvAmePiRm6gqRD/LsQaOaHlpxbODra8G69QDy7YUj/kpYb/miFHUNf0js qUuoJDotMBbRtY5CMedPaZX7GgGw2XDdMGarBStwQuU7SJTVEPTjPmSwGgRhqo1x9+ zqNse1t3g6ukBSMHbgg7XfSSTZvZ4/nAz8q5CyAsdPMAKokbYbPAmX5QZM8JiPXZmV b6z1ciZeCAJFG8zvfNJxLhevH8d71nENHpSMeDILOkswC0+RZhCFl1ypXgiSMTHeNr oD2QBPJYvo+iJ9AA9pMDbCXaOdz7TSmQryMncL5UozniBxUwxtxkjf92u2NXrMfl3+ gOCXjF78R0akA== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 314701204BC; Thu, 14 Apr 2022 10:02:19 -0400 (EDT) In-Reply-To: <4c3f728f989e832d224be1503808a682@condition-alpha.com> (Alexander Adolf's message of "Wed, 13 Apr 2022 16:44:28 +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:288393 Archived-At: > I am trying to limit the cases where eudc-capf-complete "kicks in" to > those where I think it can be assumed that its results will quite > certainly desirable. The reason is that completion-at-point works along > the functions in completion-at-point-functions, and stops when the first > function returns a completion table. Thus, by calling eudc-capf-complete > too "aggressively", more useful completion results may be prevented from > being offered to the user. Maybe EUDC shouldn't be in charge of providing a CAPF function. The CAPF function needs to understand the current document's syntax to know where an email address is expected, but that part is completely unrelated to EUDC itself (and related to the major mode instead). E.g. `ecomplete.el` doesn't provide a CAPF function, instead it only provide a completion table and relies on relevant major modes to provide a CAPF function that internally uses `ecomplete-completion-table`. This is used in `message.el` by calling this function from `message--name-table` which is the function that tries to combine the various possible backends. The decision of when/where to use `message--name-table` is made by `message-completion-alist`. Side note: `message-expand-name` may call currently (depending on circumstances) things like `eudc-expand-inline`, `bbdb-complete-name`, or `expand-abbrev` but this is deprecated and we should get rid of this part of its code (i.e. move the parts that may still be missing to `message--name-table`). We may also want to change `message--expand-name` so that backends can be added to it without changing its code. Stefan