From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: [elpa] externals/ebdb 9e7a96f: Add experimental ebdb-completion-at-point-function Date: Fri, 23 Mar 2018 13:50:31 +0800 Message-ID: <877eq3732w.fsf@ericabrahamsen.net> References: <20180323044822.32467.63948@vcs0.savannah.gnu.org> <20180323044823.1A70C20BDE@vcs0.savannah.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521784307 3429 195.159.176.226 (23 Mar 2018 05:51:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 05:51:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 06:51:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ezFc7-0000pT-2z for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 06:51:43 +0100 Original-Received: from localhost ([::1]:36185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezFeA-0002Vc-97 for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 01:53:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezFda-0002VK-Db for emacs-devel@gnu.org; Fri, 23 Mar 2018 01:53:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezFdW-0001z0-HX for emacs-devel@gnu.org; Fri, 23 Mar 2018 01:53:14 -0400 Original-Received: from [195.159.176.226] (port=37968 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ezFdW-0001xN-B1 for emacs-devel@gnu.org; Fri, 23 Mar 2018 01:53:10 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ezFbQ-00005t-Me for emacs-devel@gnu.org; Fri, 23 Mar 2018 06:51:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 68 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Mj70Pec0mnxG5Jkn7bn054vJDdQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223935 Archived-At: Stefan Monnier writes: >> +;; Experimental completion-at-point function. I'm not sure this is a >> +;; good idea yet -- with a large enough EBDB database, nearly any >> +;; string is completable, meaning the other completion-at-point >> +;; functions will rarely get a chance. >> +(defun ebdb-completion-at-point-function () > [...] >> + (when completions >> + (list start (point) >> + (mapcar >> + (lambda (str) >> + ;; Gross. >> + (if (string-match-p "@" str) >> + str >> + (capitalize str))) >> + completions) >> + '(:exclusive no))))) > Completion-at-point-functions are expected to be cheap/fast (it's normal > to call it in post-command-hook) and in order to work correctly the > completion table it returns should ideally not depend on the text > between START and END (i.e. it's OK to look at the text between > START..END in order to choose between an email completion table and > a file completion table, but it shouldn't throw away emails just > because they don't seem to match the text between START..END). > > Also in order to be effective, you want them to be selective, e.g. only > match when we're pretty sure that the completion-table we return is > relevant (e.g. we're on a "To:" line in a message-mode buffer), so it > usually depends on the major mode in which it's used. > > EBDB might elect not to provide a completion-at-point-function but > instead to provide only a completion-table (or a bunch of completion > tables). Then message-mode could use that completion-table when it > determines that we're completing an email address. Thanks for these notes! In part I was wondering if it would be useful to provide completion on contact names in other contexts besides message headers, but I suppose the right thing to do is just add contact names to the user's personal spelling dictionary, and allow them to complete names as part of spell-checking/ispell-complete-word. EBDB provides other tools for inserting contact information in random contexts. So this completion function should be targeted specifically at message/mail-mode header lines. I'll no longer override in that message-mode, but instead tie into what's already there. In message-mode, c-a-p-f contains `message-completion-function', which consults `message-completion-alist' (which contains a FIXME: "Make it possible to use the standard completion UI."), which hands off to `message-expand-name', which is hard-coded to use either eudc, bbdb, or `expand-abbrev'. There is a user option, `message-expand-name-databases', but it's mostly useless as putting new databases in there won't actually let you use them. Looks like you added that FIXME! If you outline how you think this ought to look, I can take a stab at patching message.el. At what level should these functions be intervening? My only reservation is that BBDB/EBDB mail completion first completes a contact mail address, and subsequently cycles through that contact's other addresses. Is this something that the standard mechanisms can replicate? Thanks, Eric