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: Sun, 18 Oct 2009 23:50:20 -0400 Message-ID: <1255924220.6961.1039.camel@projectile.siege-engine.com> References: <87tyxwxq6t.fsf@stupidchicken.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 1255924189 21020 80.91.229.12 (19 Oct 2009 03:49:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2009 03:49:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 05:49:39 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 1MzjFY-0002bA-Vq for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 05:49:37 +0200 Original-Received: from localhost ([127.0.0.1]:43444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzjFY-0007hs-Gy for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2009 23:49:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzjFU-0007hB-67 for emacs-devel@gnu.org; Sun, 18 Oct 2009 23:49:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzjFS-0007e3-J5 for emacs-devel@gnu.org; Sun, 18 Oct 2009 23:49:31 -0400 Original-Received: from [199.232.76.173] (port=44380 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzjFS-0007dm-E6 for emacs-devel@gnu.org; Sun, 18 Oct 2009 23:49:30 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:56681 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 1MzjFR-0000WA-W8 for emacs-devel@gnu.org; Sun, 18 Oct 2009 23:49:30 -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 n9J3oLcm018147; Sun, 18 Oct 2009 23:50:21 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n9J3oLt1018146; Sun, 18 Oct 2009 23:50:21 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: <87tyxwxq6t.fsf@stupidchicken.com> 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:116241 Archived-At: Hi, You are right, it is a bit quirky. The comment in my code about using try-completion being slow isn't about try-completion itself. It is about Semantic converting its table set into something a more normal completion prompt can use. For a large code base I work on, it used to take about 8 minutes. (I profiled it to make sure it wasn't hung, and that also slows things down a bunch, so maybe 1 minute unprofiled?) The semantic/completion code takes a shortest path approach with what you type, keeping track of old completion lists and tables and refining it as you go. I don't doubt that there's some funny stuff there that provides the quirkyness. In your example, I think it's just because "window" is an exact match. 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. 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. For your particular example in xdisp.c, it seems the contents of xdisp.c fails to parse properly. It seems to be related to the P_ macro, and one of the uses of it involving a line-end in the middle. I've narrowed it down and will see if I can fix it. The long and short of all that is, if someone wants to take on a better (consistent) completion prompt, that'd be great, and I'd be happy to do the back-end side of things as needed. (When writing the semantic completion system, I discovered that I don't really like writing completion prompts.) The API you describe sounds (in brief) sufficient to do some of what is needed. In the meantime, the current version works for me going back to Emacs 21, and XEmacs, so I'll stick with it till I can get my current release out. After that I'd want to focus on more recent Emacsen and simplifying that stuff sounds like a fine idea. Eric On Sun, 2009-10-18 at 19:00 -0400, Chong Yidong wrote: > Hi Eric, > > The completion code implemented by the semantic/complete package appears > to be quirky. For instance: > > emacs > M-x semantic-mode RET > C-x C-f ~/emacs/src/xdisp.c [visit xdisp.c in in the Emacs tree] > C-c , j > window[TAB] > > Semantic now displays a *Completions* window with the following > contents: > > Possible completions are: > window > > But this message is misleading, because that's definitely not the only > completion. Type: > > _[TAB] > > and the *Completions* window is updated with > > Possible completions are: > window_text_bottom_y window_box_width window_box_height > > On a more general note, this is one of the drawbacks to the approach > taken in semantic/complete.el, i.e. trying to reimplement completion. > We've painstakingly ironed out a lot of bugs in the standard Emacs > completion code, and it makes no sense to redo all that for Semantic > unless there's a good reason. (Not to mention inconsistency issues). > > In the commentary to semantic/complete.el, you write that using > `all-completions' and `try-completion' isn't practical because they are > too slow when there are large numbers of tags. How sure are you that > that's true? Nowadays, the completions code is very flexible; for > instance, you can pass `all-completions' and `try-completion' a > collector function instead of a flat completion table. Can't > semantic/complete.el make use of this functionality?