From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Completions in Semantic Date: Mon, 19 Oct 2009 12:26:53 -0400 Message-ID: <1255969613.6961.1056.camel@projectile.siege-engine.com> References: <87tyxwxq6t.fsf@stupidchicken.com> <1255924220.6961.1039.camel@projectile.siege-engine.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255970054 28983 80.91.229.12 (19 Oct 2009 16:34:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2009 16:34:14 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 18:34:04 2009 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.50) id 1MzvBJ-0007AP-QZ for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 18:34:02 +0200 Original-Received: from localhost ([127.0.0.1]:59033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzvBJ-0004xT-18 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 12:34:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzvB5-0004vO-T5 for emacs-devel@gnu.org; Mon, 19 Oct 2009 12:33:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzvB1-0004tj-7P for emacs-devel@gnu.org; Mon, 19 Oct 2009 12:33:43 -0400 Original-Received: from [199.232.76.173] (port=39406 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzvB0-0004tb-6w for emacs-devel@gnu.org; Mon, 19 Oct 2009 12:33:42 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:35440 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mzv3a-0008CU-QW for emacs-devel@gnu.org; Mon, 19 Oct 2009 12:26:04 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9JGQrrS019403; Mon, 19 Oct 2009 12:26:54 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n9JGQraO019402; Mon, 19 Oct 2009 12:26:53 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:116248 Archived-At: On Mon, 2009-10-19 at 09:48 -0400, Stefan Monnier wrote: > > If you look at semantic-read-symbol, it does what you suggest, and > > builds a table from the current buffer, and passes the whole thing into > > completing-read. That's ok for a single buffer, but not when you want > > some symbol from anywhere in your project. Of course, there is a basic > > assumption that the user will do something like your example below, > > typing in some prefix, before pressing TAB. If the prompt comes up and > > the user presses TAB right away, then there is no win. > > I'm not sure I understand what you're saying, but it seems what you > describe can be done as well with the "standard" completion mechanism, > since the completion-table can be a function. > > E.g. Info-complete-menu-item builds the table dynamically, using the > prefix to try and build a smaller table, and reusing the previously > built table if the completion is in the same context as the last one and > the earlier prefix is a prefix of the new one. I agree. It just wasn't available when I wrote that stuff against Emacs 21. (2003?) > > Anyway, semantic-read-symbol works fine unless there are multiple > > symbols with the same name, thus, a second thing that made me write my > > own completion code is that tags are a little special, since they have > > both names, and spacial data. Sometimes, two tags are only different > > based on their spacial data. For example, when jumping to a tag, if > > there are many hits with the same name (such as "window" in your example > > below), you can press TAB several times, and it will flash where you > > would jump to if you hit return, allowing you to differentiate. > > That would require some custom completion code, indeed, since the > current completion does not offer any hook for such things. Of course, > we could add such a hook, but we'd need to figure out where/how to > do it. There are a lot of interesting completing completion engines out there on Emacswiki. I would expect that a discussion on this topic would invite a lot of opinions from different Emacs hackers. Here are some of the things that could be discussed as worthwhile in the built-in completion system: * Differentiate between similarly named entities (as above). I called it a 'focus', meaning the user was focusing on 1 of many options, but has not chosen it. * Completion list with different text from what shows up on the prompt (another way to differentiate.) * Inline completion in a buffer. (ie - keymap, recursive-edit, minibuffer like, but in the buffer text with the intention of inserting that text..) * Option for using a CLOS object as an input to these tools. (ie - completion classes inherit from some interface.) as a way of managing persistent data between completion events. Just a favorite of mine, I'm sure. Thanks Eric