Re: [CEDET-devel] CEDET completion-at-point-function

[Eric M. Ludlam]

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