From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Completions in Semantic Date: Mon, 19 Oct 2009 09:48:22 -0400 Message-ID: References: <87tyxwxq6t.fsf@stupidchicken.com> <1255924220.6961.1039.camel@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1255960124 23058 80.91.229.12 (19 Oct 2009 13:48:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2009 13:48:44 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: eric@siege-engine.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 15:48:35 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 1MzsbD-0004G6-BZ for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 15:48:35 +0200 Original-Received: from localhost ([127.0.0.1]:54828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzsbC-0003Hl-Oh for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 09:48:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzsb6-0003Fd-Q4 for emacs-devel@gnu.org; Mon, 19 Oct 2009 09:48:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzsb1-0003BZ-Th for emacs-devel@gnu.org; Mon, 19 Oct 2009 09:48:27 -0400 Original-Received: from [199.232.76.173] (port=60744 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzsb1-0003BO-QL for emacs-devel@gnu.org; Mon, 19 Oct 2009 09:48:23 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:55210 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mzsb1-0004WW-Fx for emacs-devel@gnu.org; Mon, 19 Oct 2009 09:48:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EALMK3EpLd/m0/2dsb2JhbACBUdl3hDEEiAU X-IronPort-AV: E=Sophos;i="4.44,585,1249272000"; d="scan'208";a="47804186" Original-Received: from 75-119-249-180.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 19 Oct 2009 09:48:22 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8C2DC80E7; Mon, 19 Oct 2009 09:48:22 -0400 (EDT) In-Reply-To: <1255924220.6961.1039.camel@projectile.siege-engine.com> (Eric M. Ludlam's message of "Sun, 18 Oct 2009 23:50:20 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:116246 Archived-At: > 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. > 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. Stefan