Re: Completions in Semantic

[Eric M. Ludlam]

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?