From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 20 Oct 2015 23:13:06 -0400 Message-ID: <562702C2.6070505@gmail.com> References: <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <871tcyexa9.fsf@fimbulvetr.bsc.es> <87612a7my2.fsf@fencepost.gnu.org> <561DC925.5050001@siege-engine.com> <561E32D2.4060501@yandex.ru> <83wpum3ozk.fsf@gnu.org> <87si59ln6u.fsf@isaac.fritz.box> <56224B63.3010803@yandex.ru> <562592ED.1070104@siege-engine.com> <56262577.70107@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1445397206 10883 80.91.229.3 (21 Oct 2015 03:13:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Oct 2015 03:13:26 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Dmitry Gutov , Eric Ludlam , David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 21 05:13:21 2015 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 1Zojq3-0001Fd-BT for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2015 05:13:19 +0200 Original-Received: from localhost ([::1]:49087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zojq2-00049h-5g for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 23:13:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zojpx-00049Z-RO for emacs-devel@gnu.org; Tue, 20 Oct 2015 23:13:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zojps-00067Y-QB for emacs-devel@gnu.org; Tue, 20 Oct 2015 23:13:13 -0400 Original-Received: from mail-yk0-x232.google.com ([2607:f8b0:4002:c07::232]:34448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zojps-00067P-Kb for emacs-devel@gnu.org; Tue, 20 Oct 2015 23:13:08 -0400 Original-Received: by ykdr3 with SMTP id r3so36871216ykd.1 for ; Tue, 20 Oct 2015 20:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NdcyvVhnN+91vKEHEYKQPSMfrBSXEltXu4qKJDelZYI=; b=QjB3Mca3s7VlRSUt57H8+KAux4WLxaa+PNS2AxEWZ0JA4FXpit2d3ezTl/Ld/DI/fa HKcSzA6qWHCA5j2yLkmXBZRk1IPvk50caixKk2YuU+Fu+8SdsvHRnd+oJ5GQT40xn5G5 +IEj+jTQ6xhj8FeAK7a+YsUCVjx1yhBAMh2jKXiqaDsdjH9BA1QpLdea5DzoKT5ZSVZY 6JCRI44gLKyPOVbV86JDzS/2kGkCE1VIgFXzo6oBywu+p8z2BFysJ136+OYCGUY/D4nh ZPqk8ZaLDOx3e8iy/wGGa0oq3M2LKy4d1r7HgC2KA+I4w6X/wUO4oFKQIGrD5Y/zGKNk iNkw== X-Received: by 10.129.36.11 with SMTP id k11mr4967447ywk.2.1445397188185; Tue, 20 Oct 2015 20:13:08 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id r63sm4214135ywb.43.2015.10.20.20.13.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 20:13:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <56262577.70107@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::232 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:192255 Archived-At: On 10/20/2015 07:28 AM, Dmitry Gutov wrote: > On 10/20/2015 04:03 AM, Eric Ludlam wrote: > >> We should poke at this. Can you share a little about what your tool >> does? Then perhaps we hypothesize about the efficacy of integrating >> into CEDET as an example of integrating external tools. > > It probably wouldn't gain too much from CEDET integration. Ruby support tooling itself would not benefit from CEDET integration, but tools built on CEDET would gain Ruby support, and that improves the diversity of Ruby related tools available. > It has: > > - Server, serving JSON over HTTP, with a RPC-like protocol. > > - Emacs client in the shape of a minor mode. It defines a > completion-at-point-functions element and a keymap with essentially > three commands: "jump to the definition", "jump back", "show > documentation for the method at point". > Inside this feature you must have a way to query for the location of a particular symbol, and convert a symbol into a doc reference. In CEDET speak, the tooling that converts a symbol into a location would be a special kind of Semantic Database. This could be tied to a project or tied in as a system database depending on what it is querying. Or one of each. The job of such databases is to provide a search for tag by name, completion substring, regexp, and for languages that care, type. The output is a list of matches as faux tags. If an application wanted to know more about the symbol, it would pull in the reference file, and extract real tag data using whatever parser is available. This would enable Semantic's jump to tag system to be as accurate as yours. I am not sure what your doc piece might be like. There is some limited support for finding doc strings, but usually it just looks for comments preceding a tag. > - To determine the current context (which would be similar to "current > tag" in Semantic), it calls ruby-add-log-current-method and parses the > returned string. I've improved that function in ruby-mode a year or > two ago, and it's pretty accurate. We used to have a way to tweak add-log but I think the mechanism is for an older version of Emacs where we needed to use advice. It would make sense to update this if there is a better way. > Robe is also pretty hacky compared to most other similar tools: > > - The server loads itself into and runs from an REPL buffer. We either > expect the user to already have such a REPL running (with the project > loaded), or offer to launch one automatically (which fails in certain > configurations). > > - It doesn't support multiple projects in the same Emacs session. > An EDE type project for ruby (whatever that looks like) would provide a place to hang project specific REPL buffers as needed. > - It misses some trivial opportunities to infer the type of a local > variable. That would be my first priority to work on... when I deal > with all that project and xref stuff in the core, I guess. I'm not sure which code bit you are referencing here. If you do your tag parsing with a semantic grammar, then you can optionally use that same grammar to parse function bodies, and thus make detecting local variable types a bit easier. I'm speculating however as I am not familiar with Ruby. There is a wisent based grammar for Ruby in the 'contrib' area that seems straightforward. It would probably not be much of a stretch to build one with the right releases to include in Emacs, solve this one problem, and then get support from other CEDET tools. Eric