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: Wed, 18 Jun 2014 21:20:23 -0400 Message-ID: <53A23AD7.3050007@siege-engine.com> References: <53717C7E.60208@siege-engine.com> <539DEC30.4050403@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 1403140850 8156 80.91.229.3 (19 Jun 2014 01:20:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 01:20:50 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@gnu.org, cedet-devel@lists.sourceforge.net To: Stefan Monnier Original-X-From: cedet-devel-bounces@lists.sourceforge.net Thu Jun 19 03:20:40 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 1WxR1r-0002u0-F2 for sf-cedet-devel@m.gmane.org; Thu, 19 Jun 2014 03:20:39 +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 1WxR1m-0006jG-Rs; Thu, 19 Jun 2014 01:20:34 +0000 Original-Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WxR1k-0006jB-Ri for cedet-devel@lists.sourceforge.net; Thu, 19 Jun 2014 01:20:32 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.172 as permitted sender) client-ip=209.85.216.172; envelope-from=ericludlam@gmail.com; helo=mail-qc0-f172.google.com; Original-Received: from mail-qc0-f172.google.com ([209.85.216.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxR1i-0000xx-Ud for cedet-devel@lists.sourceforge.net; Thu, 19 Jun 2014 01:20:32 +0000 Original-Received: by mail-qc0-f172.google.com with SMTP id o8so1563706qcw.17 for ; Wed, 18 Jun 2014 18:20:25 -0700 (PDT) X-Received: by 10.140.50.168 with SMTP id s37mr2434929qga.36.1403140825300; Wed, 18 Jun 2014 18:20:25 -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 2sm5988378qag.28.2014.06.18.18.20.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 18:20:24 -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: 1WxR1i-0000xx-Ud 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:6866 gmane.emacs.devel:172525 Archived-At: 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. 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