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: Completion functions in message-mode (was: [elpa] externals/ebdb 9e7a96f: Add experimental ebdb-completion-at-point-function) Date: Fri, 13 Apr 2018 18:02:58 -0700 Message-ID: <87h8oer459.fsf_-_@ericabrahamsen.net> References: <20180323044822.32467.63948@vcs0.savannah.gnu.org> <20180323044823.1A70C20BDE@vcs0.savannah.gnu.org> <877eq3732w.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523667672 2929 195.159.176.226 (14 Apr 2018 01:01:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Apr 2018 01:01:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 14 03:01:07 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 1f79Yx-0000eS-EN for ged-emacs-devel@m.gmane.org; Sat, 14 Apr 2018 03:01:07 +0200 Original-Received: from localhost ([::1]:41831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f79b4-00027x-2V for ged-emacs-devel@m.gmane.org; Fri, 13 Apr 2018 21:03:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f79aw-00026w-BJ for emacs-devel@gnu.org; Fri, 13 Apr 2018 21:03:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f79as-0002h5-A4 for emacs-devel@gnu.org; Fri, 13 Apr 2018 21:03:10 -0400 Original-Received: from mail.ericabrahamsen.net ([50.56.99.223]:45758) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f79as-0002fs-4Z for emacs-devel@gnu.org; Fri, 13 Apr 2018 21:03:06 -0400 Original-Received: from localhost (71-35-188-108.tukw.qwest.net [71.35.188.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id CFBD7BE921; Sat, 14 Apr 2018 01:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ericabrahamsen.net; s=mail; t=1523667779; bh=tNASwkOUU8WilmrC7Dyb+VkCNfRtV7NT+2W+z3dH58g=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=QKfrNUh+mJ6dl+uoiajR3jCpxdky/pU2FjqS5HV3LTLSZINgWh2zqgMEtvEiGU/io 5kKpSGpLltj0+ctjO+i0Vs4haJyP+vY1+YcEo1CgyWHd8FEnjlr0bJwFKRdt5yNO9G 4novcA42nxIXvwsTY4kIx7plTq0QtOEISwT9gWNw= In-Reply-To: (Stefan Monnier's message of "Fri, 23 Mar 2018 08:23:07 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 50.56.99.223 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:224574 Archived-At: Stefan Monnier writes: >> 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? > > One of the main issue is preserving backward compatibility with existing > functions the user may have set in message-completion-alist. > > I have already some local patches to try and do some of that, so see > patch below (I hand-edited it to remove irrelevant other cosmetic > changes, so don't try to pass it to `patch`). Okay, I'm finally coming back around to this, and I need a bit more of an overview to know what to do. Lars seems to have come in from the cold, so I'm copying him here. Leaving backward compatibility aside for a second, here's my take on things: What we've got is: message-mode binds TAB to `message-tab', which calls `completion-at-point' and, if that doesn't work, falls back to other things. message-mode adds `message-completion-function' to `completion-functions-at-point', so TAB ends up calling that function first. If point is in a viable header, the function calls `message-expand-group' or `message-expand-name' depending on the header, but either way _always_ returns a value so that it prevents any other capf functions from running. If point isn't in a viable header, we get the "falls back to other things" behavior. `message-expand-name' is the one that hands off to EUDC, BBDB, etc. The whole issue is that these package functions do their own completion, rather than interfacing with `completion-at-point'. What we _want_ is (and I'm partially guessing here): message-mode adds message-expand-group and message-tab-body-function to `completion-at-point-functions'. Both of these functions check if they're in an appropriate location, and bail if not, allowing other functions to do their thing. Packages such as EUDC and BBDB put their own functions in `completion-at-point-functions' (in the message-mode hook). The first thing these functions do is test if they're in an appropriate header, and bail if not. Otherwise they return an appropriate value for c-a-p, ie (START END COLLECTION), rather than doing their own completion. Does this seem about right? Backwards compatibility is still an issue, but that's what Stefan's patch addresses. Eric