From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.cedet,gmane.emacs.devel Subject: Re: CEDET completion-at-point-function Date: Sun, 15 Jun 2014 14:55:44 -0400 Message-ID: <539DEC30.4050403@siege-engine.com> References: <53717C7E.60208@siege-engine.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1402858568 20052 80.91.229.3 (15 Jun 2014 18:56:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Jun 2014 18:56:08 +0000 (UTC) Cc: dgutov@gnu.org, cedet-devel@lists.sourceforge.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: cedet-devel-bounces@lists.sourceforge.net Sun Jun 15 20:56:00 2014 Return-path: Envelope-to: sf-cedet-devel@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WwFax-00087p-Ti for sf-cedet-devel@m.gmane.org; Sun, 15 Jun 2014 20:56:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwFat-0008Jg-RA; Sun, 15 Jun 2014 18:55:55 +0000 Original-Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwFas-0008JY-Cp for cedet-devel@lists.sourceforge.net; Sun, 15 Jun 2014 18:55:54 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.178 as permitted sender) client-ip=209.85.216.178; envelope-from=ericludlam@gmail.com; helo=mail-qc0-f178.google.com; Original-Received: from mail-qc0-f178.google.com ([209.85.216.178]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwFaq-0008MF-Hz for cedet-devel@lists.sourceforge.net; Sun, 15 Jun 2014 18:55:54 +0000 Original-Received: by mail-qc0-f178.google.com with SMTP id c9so6509086qcz.37 for ; Sun, 15 Jun 2014 11:55:47 -0700 (PDT) X-Received: by 10.140.100.176 with SMTP id s45mr3923101qge.106.1402858546989; Sun, 15 Jun 2014 11:55:46 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-71-184-209-46.bstnma.fios.verizon.net. [71.184.209.46]) by mx.google.com with ESMTPSA id q10sm17836504qah.9.2014.06.15.11.55.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Jun 2014 11:55:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ericludlam[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WwFaq-0008MF-Hz X-BeenThere: cedet-devel@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Development discussions for CEDET projects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cedet-devel-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cedet:6862 gmane.emacs.devel:172472 Archived-At: 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 ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems