Re: CEDET completion-at-point-function

["Eric M. Ludlam" <eric@siege-engine.com>]

On 06/16/2014 04:52 PM, Stefan Monnier wrote:
>> Splitting the implementation apart seems like a good idea based on the way
>> you are using it.
>
> It's an incompatible change, so I'm interested in your opinion about the
> consequences.  IOW how likely is it that there are existing overrides of
> those thingies "out in the wild"?  Those in Emacs's CEDET code are of course
> easy/trivial to fix.
> I (currently) need two such incompatible changes:
> - one to split the "get symbol-and-bounds at point" from the actual
>    analysis of the current context.

I do not think this will be a compatibility issue.  The srecoder mode 
has an overload here you could test with to see if it becomes a problem 
in the .srt (template) files.

> - one to separate the insertion of the tag's name from the insertion of
>    supplemental text after it such as "()".

I doubt this was ever overloaded.  Almost all uses of semantic's 
completion API are directly via semantic-analyze-possible-completions, 
and they handle their own insertion.

[...]

>> What is particularly interesting is that if you know you have p->f, then
>> p must be some sort of struct/class, so you could filter out ll the symbols
>> that are not one of those.  That is a new kind of filter the engine doesn't
>> do yet.
>
> I think the generic completion code would already take care of that.
> E.g. it currently completes "/us/s/man" to "/usr/share/man" even if
> "/us/s/m" only completes to "/usr/s/m" because there are "m" completions
> under "/usr/sbin", "/usr/src", and "/usr/share".
>
> Tho admittedly, the above works because the completions for "/usr/s"
> look like "share/" rather than "share".  So we might need to arrange for
> the completion table to return "port->" rather than "port" when "port"
> is a variable of type "pointer to struct/class", and of course only do
> it when completing "the left hand side".
>
> The "completion-boundaries" is a way for the completion table to tell
> the completion code about how "/u/b/em" is split into 3 parts that are
> completed "separately".

I think I'll need to play with completion tables and completion 
boundaries to better comment.  There is an expense expanding from some 
symbol p (which could be port) past the ->, and to the next symbol.  If 
there happen to be 10 possible "p" expansions that are all also some 
sort of struct, then p->f, the f could be a rather large  number of 
possible things, and thus be expensive if not handled carefully.  For 
example if the code had 4 variables "port1" "port2", etc that were all 
the same type.  When expanding the ->f, that should happen once instead 
of 4 times because we know all the types are the same.

When expanding p->f->a->d there are 3 different kinds of completion.

The first symbol "p" could be a rather large number of things from the 
global name space.   "f" and "a" are pretty easy, since you are now in 
the "expand a data type" space, semantic builds a nice datatype table to 
reference.  "d" is generally derived the same as f and a, but we apply 
one last filter of the return type, so if you had:

q = p->f->a->d;

Then d's type should be similar to q.

If you are skipping parts of the completion engine, you may miss some of 
the extra filters, or some of the optimizations.

I hope that helps, though I'm pretty sure it won't impact your current 
experiment much since these are all thoughts of optional optimizations.

Eric

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems