From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: Completing with anything Date: Tue, 24 May 2011 11:16:41 +0200 Message-ID: <87aaecihl2.fsf@gmail.com> References: <87r5bhysp6.fsf@keller.adm.naquadah.org> <87k4h7ua23.fsf@member.fsf.org> <87vd0romky.fsf@keller.adm.naquadah.org> <87mxm2na63.fsf@member.fsf.org> <87vd0qfhu3.fsf@member.fsf.org> <87y63jpii5.fsf@keller.adm.naquadah.org> <871v0ecwe4.fsf@keller.adm.naquadah.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306228647 27994 80.91.229.12 (24 May 2011 09:17:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 09:17:27 +0000 (UTC) Cc: emacs-orgmode@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 24 11:17:23 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QOnju-0005hR-Nn for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 11:17:22 +0200 Original-Received: from localhost ([::1]:34299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOnju-0003yQ-9n for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 05:17:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOnjo-0003yD-7z for emacs-devel@gnu.org; Tue, 24 May 2011 05:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOnjn-0002tU-5U for emacs-devel@gnu.org; Tue, 24 May 2011 05:17:16 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:46889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOnjm-0002tF-Po for emacs-devel@gnu.org; Tue, 24 May 2011 05:17:15 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QOnjk-0005dd-LM for emacs-devel@gnu.org; Tue, 24 May 2011 11:17:12 +0200 Original-Received: from ney92-7-78-233-218-202.fbx.proxad.net ([78.233.218.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2011 11:17:12 +0200 Original-Received: from antoine.levitt by ney92-7-78-233-218-202.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2011 11:17:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.emacs.devel Original-Lines: 31 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ney92-7-78-233-218-202.fbx.proxad.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139674 gmane.emacs.orgmode:42170 Archived-At: 24/05/11 05:14, Stefan Monnier >> > So at least cycling-completion seems fundamentally incompatible with >> > this idea of abbrev-expansion-after-completion, at least if you want to >> > allow arbitrarily complex abbrevs like skeletons. >> Indeed, this is a real problem. > > I've now added a :exit-function property that > completion-at-point-functions can return which is a function that gets > called when completion is finished. It operates outside of the > completion-table, so has access to the buffer text and can do things > like abbrev-expand. > > It gets a status argument which tells it whether the completion is > `exact' (basically, it's valid according to the completion-table, but > there may be further completions available), `sole' (it's the only > completion), and `finished' (not only it's the sole completion, but the > user is not expected to want to change it). `sole' is used by cycling, > so the :exit-function can call abbrev-expand when the status is > `finished' and it won't interfere with cycling (which simply won't > benefit from abbrev-expansion). So, could you add 'failed, which means that no function was able to complete? That way I could do something like (setq completion-extra-properties '(:exit-function my-exit-function)) (defun my-exit-function (string finished) (when (eq finished 'failed) (dabbrev-expand))) and always get a dabbrev-expand as fallback to completion-at-point?