From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.cedet Subject: Re: [CEDET-devel] CEDET completion-at-point-function Date: Mon, 16 Jun 2014 16:52:35 -0400 Message-ID: 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 X-Trace: ger.gmane.org 1402952011 410 80.91.229.3 (16 Jun 2014 20:53:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Jun 2014 20:53:31 +0000 (UTC) Cc: dgutov@gnu.org, cedet-devel@lists.sourceforge.net, emacs-devel@gnu.org To: "Eric M. Ludlam" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 16 22:53:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wwdu7-0008SU-CV for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 22:53:23 +0200 Original-Received: from localhost ([::1]:46250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwdu7-00024d-1Y for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 16:53:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwdtv-0001wf-Lj for emacs-devel@gnu.org; Mon, 16 Jun 2014 16:53:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wwdtm-0002mc-27 for emacs-devel@gnu.org; Mon, 16 Jun 2014 16:53:11 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:56494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwdtl-0002lD-4O for emacs-devel@gnu.org; Mon, 16 Jun 2014 16:53:01 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id C454824133; Mon, 16 Jun 2014 16:52:59 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 5F71A1E5B74; Mon, 16 Jun 2014 16:52:35 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 40CCDB4167; Mon, 16 Jun 2014 16:52:35 -0400 (EDT) In-Reply-To: <539DEC30.4050403@siege-engine.com> (Eric M. Ludlam's message of "Sun, 15 Jun 2014 14:55:44 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.6, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_MONNAIE 0.22, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172485 gmane.emacs.cedet:6863 Archived-At: > 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