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: Completing with anything Date: Fri, 18 Mar 2011 14:16:38 -0400 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1300472216 18113 80.91.229.12 (18 Mar 2011 18:16:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Mar 2011 18:16:56 +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 Fri Mar 18 19:16:52 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q0eEG-0001gG-6d for ged-emacs-devel@m.gmane.org; Fri, 18 Mar 2011 19:16:52 +0100 Original-Received: from localhost ([127.0.0.1]:55132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0eEF-00086n-Jr for ged-emacs-devel@m.gmane.org; Fri, 18 Mar 2011 14:16:51 -0400 Original-Received: from [140.186.70.92] (port=35315 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0eE7-00085v-7r for emacs-devel@gnu.org; Fri, 18 Mar 2011 14:16:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0eE6-0001oq-4N for emacs-devel@gnu.org; Fri, 18 Mar 2011 14:16:43 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:43222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0eE3-0001nv-So; Fri, 18 Mar 2011 14:16:39 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p2IIGc1J028512; Fri, 18 Mar 2011 14:16:38 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 90E231302AB; Fri, 18 Mar 2011 14:16:38 -0400 (EDT) In-Reply-To: (Julien Danjou's message of "Fri, 18 Mar 2011 16:00:18 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3800=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3800> : streams <609961> : uri <830191> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137408 gmane.emacs.orgmode:39731 Archived-At: >> For more complex cases, there is also the issue of what to do when some >> parts of the completion are case-sensitive and other parts aren't >> (e.g. completion of case-sensitive envvars in case-insensitive file >> names), although this is less important for completion-at-point than >> for minibuffer completion since you don't have to return a table that >> covers the completion of the whole field (composed of file names and >> env-vars, for example), and instead you can just limit the completion to >> the particular subfield. > There's still something wrong to me in the solution provided by Tassilo. > It works fine, but it is returning a function to bypass the usual > completion code completion code. Ignoring case, like doing smarter > completion (e.g. where the typed prefix does not match the returned > choices at all) is something that is very useful. > Therefore I wonder if we should either: > - Edit `completion-at-point-functions' docstring to remove the word > "discouraged" in that sentence: > "or a function of no argument to perform completion (discouraged),"; There's a misunderstanding: AFAIK the patch sent by Tassilo does not make the completion-at-point-function return a "function that performs completion" but does properly return completion data (i.e. region start, region end, and completion table), part of which happens to be represented by a function. I.e. this is not one of the discouraged cases. > - Make completing code allows to replace the region being completed with > somethig that does not match at all. AFAIK that's already the case, tho it depends on lots of factors, such as what you mean by "completing code". Stefan