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

[Eric M. Ludlam]

On 06/14/2014 11:14 PM, Stefan Monnier wrote:
> Anyway, I've since figured that it's simpler to use a new file.
>
> Here is my work-in-progress code.  I'd welcome comments on it, since
> I don't know much about Semantic I've had to make a few changes to it
> (see the overloaded methods I had to change in semantic/analyze.el and
> semantic/ia.el, meaning that the "overloadability" was moved to a new
> method) as well as make some assumptions about some of its code (see
> comment in semantic/analyze/complete.el).

Thanks for looking into this.  I have a few thoughts, though I wasn't 
always certain what your goal was in a particular change;


> === modified file 'lisp/cedet/semantic/analyze.el'
> --- lisp/cedet/semantic/analyze.el      2014-01-01 07:43:34 +0000
> +++ lisp/cedet/semantic/analyze.el      2014-06-15 02:47:17 +0000

[...]


> +      ;; FIXME: Code duplication!  This should use something like
> +      ;; condition-case-unless-debug!
>         (if debug-on-error

I was unaware of this.  I'll start using it instead.

> +;;;###autoload
> +(defun semantic-analyze-current-context (&optional position interactive)
> +  "Analyze the current context at optional POSITION.
> +If called interactively, display interesting information about POSITION
> +in a separate buffer.
> +Returns an object based on symbol `semantic-analyze-context'.
> +
> +This function can be overridden with the symbol `analyze-context'.
> +When overriding this function, your override will be called while
> +cursor is at POSITION.  In addition, your function will not be called
> +if a cached copy of the return object is found."
> +  ;; FIXME: Shouldn't `analyze-context' above be `current-context'?

That whole piece of doc should be removed, as there is no override 
symbol interface to 'mode-local' anymore.   Thanks for noticing that.

Splitting the implementation apart seems like a good idea based on the 
way you are using it.

> === modified file 'lisp/cedet/semantic/analyze/complete.el'
> --- lisp/cedet/semantic/analyze/complete.el     2014-01-01 07:43:34 +0000
> +++ lisp/cedet/semantic/analyze/complete.el     2014-06-15 03:00:28 +0000
> @@ -129,6 +129,14 @@
>          (do-typeconstraint (not (memq 'no-tc flags)))
>          (do-unique (not (memq 'no-unique flags)))
>          )
> +    ;; If the buffer text is "p->f_a", this code will only give us the fields
> +    ;; of "p" which start with "f_a".  But we may want to complete it to
> +    ;; "p->fastmap_accurate".
> +    ;; In semantic/capf.el we hack around it by fudging `prefix' so it doesn't
> +    ;; exactly contain the buffer text (e.g. it might pretend the user only
> +    ;; typed "p->f" and let the generic completion code take responsibility for
> +    ;; filtering out completions which don't contain the "_a").
> +    ;; So don't assume that `prefix' really reflects the content of the buffer.

I use old school completion in here from before the new fuzzy matching 
was introduced.

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.

> === added file 'lisp/cedet/semantic/capf.el'
> --- lisp/cedet/semantic/capf.el 1970-01-01 00:00:00 +0000
> +++ lisp/cedet/semantic/capf.el 2014-06-15 03:03:44 +0000

[...]

> +(defun semantic-capf-completion-table (sab cache)
> +  ;; Calculating completions is a two step process.
> +  ;;
> +  ;; The first analyzes the current context, which finds tags for
> +  ;; all the stuff that may be referenced by the code around POS.
> +  ;;
> +  ;; The second step derives completions from that context.
> +  (let ((buf (current-buffer)))
> +    (completion-table-dynamic
> +     (lambda (pre)
> +       (with-current-buffer buf
> +         ;; FIXME: Figure out how to use completion-boundaries to be able to do
> +         ;; partial completion of "p->f" to "port->fastmap".

Interesting idea.  As I'm only inspecting the patch and I'm not quite 
sure how we got here or what completion-boundaries are, but 
`semantic-ctxt-current-symbol-and-bounds' will provide back both "p" and 
"f", and the completion engine would throw an error if there is no 'p'. 
 When deriving the current-context the returned class shows that more 
than one symbol in the prefix is unfound.  This is a notice that you 
could do some fuzzy cross-symbol matching for a case like this.

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

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.   The s-a-b function would need to be upgraded to 
interpret the boundary text into an indication of the completion filter.

Sounds fun!  I'd be tempted to investigate that when I'm done with my 
current EDE enhancements task.

Eric