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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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.
- one to separate the insertion of the tag's name from the insertion of
  supplemental text after it such as "()".

> The ideal solution would be to have a new function such as
> `semantic-find-tags-for-completion-fuzzy' or whichever word you use to
> describe the behavior to fit in with all the other semantic-find-* 
> functions.  Since the completion engine also accepts a set of flags,
> semantic/capf could just pass in a flag for fuzzy matching instead of trying
> to work around the missing feature.

It could be useful for CEDET to do the fuzzy matching in some cases, but
so far I'm not interested in this option.  Instead, I want to handle the
case where the fuzzy matching is performed by the generic completion
code, according to `completion-styles'.

The patch I sent does correctly let one complete "p->f_a" to
"p->fastmap_accurate".

> I think the only way to have the semantic completion engine provide the data
> to do that is for the s-a-b function to return bounds for each found symbol
> instead of just the last one.

Indeed, that's the first step.

> There are a bunch of assumptions around this
> so it would be a fundamental change, but also valuable.  It would certainly
> be possible to start with 'p' and walk through the unknown strings doing
> completion along the way if we knew where those text strings were in
> the buffer.

That's what the generic completion code would do if we could give it the
right info.  It does that already when you complete "/us/s/man" to
"/usr/share/man".

> 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".


        Stefan