[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [CEDET-devel] CEDET completion-at-point-function
Eric M. Ludlam
Re: [CEDET-devel] CEDET completion-at-point-function
Sun, 15 Jun 2014 14:55:44 -0400
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre
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!
I was unaware of this. I'll start using it instead.
+(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
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)))
+ (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.