From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: [O] Re: Completing with anything Date: Wed, 04 May 2011 12:07:23 -0300 Message-ID: References: <87r5bhysp6.fsf@keller.adm.naquadah.org> <878vxovsym.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304521661 27733 80.91.229.12 (4 May 2011 15:07:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 May 2011 15:07:41 +0000 (UTC) Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 04 17:07:36 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 1QHdfs-0003W9-5c for ged-emacs-devel@m.gmane.org; Wed, 04 May 2011 17:07:36 +0200 Original-Received: from localhost ([::1]:41600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHdfr-0008JR-IW for ged-emacs-devel@m.gmane.org; Wed, 04 May 2011 11:07:35 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHdfo-0008JL-Nv for emacs-devel@gnu.org; Wed, 04 May 2011 11:07:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHdfj-0000SL-2s for emacs-devel@gnu.org; Wed, 04 May 2011 11:07:32 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:43377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHdfj-0000SH-1S; Wed, 04 May 2011 11:07:27 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:12078 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QHdfi-0004Yz-NQ; Wed, 04 May 2011 11:07:27 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1A89C662FC; Wed, 4 May 2011 12:07:23 -0300 (ART) In-Reply-To: (Julien Danjou's message of "Tue, 12 Apr 2011 11:48:41 +0200") 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: 140.186.70.10 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:139107 gmane.emacs.orgmode:41578 Archived-At: >> Hmm... good point, doing it in completion-choices is not reliable, tho >> using as completion table something like: >> >> (lambda (string pred action) >> (let ((res (complete-with-action action completion-choices string pred))) >> (if (and (eq action nil) >> (assq (if (eq res t) string res) )) >> (cdr (assq (if (eq res t) string res) )) >> res))) >> >> should work OK for prefix completion, but that means using the expansion >> "by hand" rather than via expand-abbrev, which may not be an option. > Yeah. That does not looks like a simple/good option. > As it stands, I guess the bbdb solution to return a function doing the > replacement rather than trying to return a list and conform with the > (current) way of doing completion is really simpler, unfortunately. :( While taking a look at adding the necessary functionality to minibuffer.el, I bumped into a problem: If you complete "ni" to "nic" which is a valid alias and you also have a "nicolas" alias, running expand-abbrev after the completion may not be right since it will prevent you from getting to "nicolas". Now, this is a minor problem. But the more general case is when the user has set completion-cycle-threshold so that completion happened via cycling: the string after completion is a valid abbrev (presumably) but calling expand-abbrev on it will interfere with the cycling in a big way (the details of what will happen depend on the way cycling is implemented and what kind of abbrevs we're talking about). 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. Could you give me an idea of what kind of abbrevs the code should try to accommodate? Stefan