[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric M. Ludlam
Subject: Re: [CEDET-devel] CEDET completion-at-point-function
Date: Wed, 18 Jun 2014 21:20:23 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]