From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: emacs-devel@gnu.org
Subject: Re: Completions in Semantic
Date: Sun, 18 Oct 2009 23:50:20 -0400 [thread overview]
Message-ID: <1255924220.6961.1039.camel@projectile.siege-engine.com> (raw)
In-Reply-To: <87tyxwxq6t.fsf@stupidchicken.com>
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?
next prev parent reply other threads:[~2009-10-19 3:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-18 23:00 Completions in Semantic Chong Yidong
2009-10-18 23:55 ` Miles Bader
2009-10-19 3:50 ` Eric M. Ludlam [this message]
2009-10-19 13:48 ` Stefan Monnier
2009-10-19 16:26 ` Eric M. Ludlam
2009-10-19 18:29 ` Stefan Monnier
2009-10-19 19:33 ` Eric M. Ludlam
2009-10-19 20:06 ` Stefan Monnier
2009-10-19 22:17 ` Eric M. Ludlam
2009-10-20 0:07 ` Lennart Borgman
2009-10-30 21:17 ` Toby Cubitt
2009-10-30 21:37 ` Lennart Borgman
2009-10-20 0:14 ` Stefan Monnier
2009-10-20 20:20 ` Eric M. Ludlam
2009-10-21 10:58 ` Lluis
2009-10-21 12:35 ` Eric M. Ludlam
2009-10-21 13:28 ` Lluis
2009-10-21 17:35 ` Eric M. Ludlam
2009-10-22 20:12 ` Stefan Monnier
2009-10-27 21:21 ` Lluis
2009-10-28 0:56 ` Stefan Monnier
2009-10-28 2:25 ` Eric M. Ludlam
2009-10-28 3:23 ` Stefan Monnier
2009-10-29 14:38 ` Lluis
2009-10-31 20:18 ` Stefan Monnier
2009-11-01 16:01 ` Lluís
2009-11-02 6:12 ` Stefan Monnier
2009-11-02 12:13 ` Eric M. Ludlam
2009-10-22 20:00 ` Stefan Monnier
2009-10-19 23:52 ` Eric M. Ludlam
2009-10-21 14:07 ` Chong Yidong
2009-10-21 16:10 ` Eric M. Ludlam
2009-10-23 1:01 ` Chong Yidong
2009-10-23 1:28 ` Eric M. Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1255924220.6961.1039.camel@projectile.siege-engine.com \
--to=eric@siege-engine.com \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).