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: master 620ac67355: EUDC: Add completion-at-point support Date: Tue, 10 May 2022 18:06:33 -0400 Message-ID: References: <165221712797.22071.2062685793306083928@vcs2.savannah.gnu.org> <20220510211208.6A954C01683@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20522"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Alexander Adolf To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 11 00:08:29 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 1noY1s-00058x-6M for ged-emacs-devel@m.gmane-mx.org; Wed, 11 May 2022 00:08:28 +0200 Original-Received: from localhost ([::1]:33032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1noY1q-0006qM-Jb for ged-emacs-devel@m.gmane-mx.org; Tue, 10 May 2022 18:08:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40866) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1noY0I-0005nu-K6 for emacs-devel@gnu.org; Tue, 10 May 2022 18:06:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45492) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1noY0E-0000kZ-Qu for emacs-devel@gnu.org; Tue, 10 May 2022 18:06:49 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 63C374427E8; Tue, 10 May 2022 18:06:36 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 75E7E4427EA; Tue, 10 May 2022 18:06:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1652220394; bh=TftWWb4tNYruvKIPGhBV6YWcLfHtk15vbbksokvUgNM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Q7JgsDtztXAx1SXOObM/raY06l3U/BMYW+V6wQhJVWhUZR29wSEG3KjuRQmY4dSwV 88c7E7lK4j5tZEqwsxm0FLzlr89ovFDj7x/ajopM+STVyNg9FAUNlsiaZuxJm7qEQh MKcV79FShamQvo7LJ2BhJstPDRFCjuWA589ec9H6w8eLGGjR3HwMo2AwSRfk/2rQgn 7nfafa9r8HjmL16LTTnBRhgPtM9O+fNouMAegcnzxbi/J3+Oc24wAt7kPbC4AEl2t1 pwtcwrc67oI7b/q1XOMpcc6HM2/BerQClgK/0ecJDGzwtPp00GSRTwZxw3Wi8eyuLw aYp/9k32VR4IA== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4B42B120963; Tue, 10 May 2022 18:06:34 -0400 (EDT) In-Reply-To: <20220510211208.6A954C01683@vcs2.savannah.gnu.org> (Thomas Fitzsimmons's message of "Tue, 10 May 2022 17:12:08 -0400 (EDT)") 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:289604 Archived-At: > +;; The first mechanism is intended for use by the modes listed in > +;; `eudc-capf-modes', and relies on these modes adding > +;; `eudc-capf-complete' to `completion-at-point-functions', as > +;; would be usually done for any general-purpose completion > +;; function. In this mode of operation, and in order to offer > +;; email addresses only in contexts where the user would expect > +;; them, a check is performed whether point is on a line that is a > +;; message header field suitable for email addresses, such as for > +;; example "To:", "Cc:", etc. > +;; > +;; The second mechanism is intended for when the user modifies > +;; `message-completion-alist' to replace `message-expand-name' with > +;; the function `eudc-capf-message-expand-name'. As a result, > +;; minibuffer completion (`completing-read') for email addresses > +;; would no longer enabled in `message-mode', but > +;; `completion-at-point' (in-buffer completion) only. Could you contrast the behavior of this new code with the one we get from `message--name-table` (i.e. when setting `message-expand-name-standard-ui`)? Looking at the code in message.el it seems it should provide a fairly similar behavior. It seems to do similar caching, uses (eudc-query-with-words (split-string orig-string "[ \t]+")) like your code, tho your code passes an extra t arg to "try-all-servers". Maybe message.el should also use that? Any other difference? Stefan