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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: Re: 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Julien Danjou's message of "Tue, 12 Apr 2011 11:48:41 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org To: Tassilo Horn Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org List-Id: emacs-orgmode.gnu.org >> 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