From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Wed, 21 Oct 2015 13:54:06 +0300 Message-ID: <56276ECE.3090508@yandex.ru> 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> <562702C2.6070505@gmail.com> 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 1445490679 16521 80.91.229.3 (22 Oct 2015 05:11:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 05:11:19 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Eric Ludlam , Eric Ludlam , David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 22 07:10:58 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 1Zp89R-0003fc-Po for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 07:10:58 +0200 Original-Received: from localhost ([::1]:51440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zot6x-0006yW-0N for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2015 09:07:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zor2B-0004x7-1V for emacs-devel@gnu.org; Wed, 21 Oct 2015 06:54:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zor26-0006dw-Vx for emacs-devel@gnu.org; Wed, 21 Oct 2015 06:54:18 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:33253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zor26-0006bu-Cy for emacs-devel@gnu.org; Wed, 21 Oct 2015 06:54:14 -0400 Original-Received: by wijp11 with SMTP id p11so88702823wij.0 for ; Wed, 21 Oct 2015 03:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=wT1etDuvoeEL0rUGDs/T9WUz80eLZDq2RmdbLN4eK/A=; b=EMprTyTTrgpzWenKh3c20+Hu7znYh+OEp+uKC0Le8IV95eP6k/WkZsih6YhyvqPssY +f7GQZWJg3p+yxBcHZ9VvF3gU9l+3+ah1SLtv7KvTiGsuMKN7l+9NbWTRG+/On5xJvUY w9jqP/b9+E+KWA6m5bUtQqUDESCXADowgIr+huHD0wpVZ7RMxsQFO4WyeLz28u/hTUTO gNqujFh0zK6xeX4vxCQtE7vClG9FHipO+oq0UwrfNC6iCs3DU/s13lY8VYoR55XAti02 8Ifu8f/I9cVWsbI683Z2ENs+yxfWHIc07p2974KOPARZuM3G1Y+LSvc76QcecYXDBrlD zdtw== X-Received: by 10.180.35.38 with SMTP id e6mr8823501wij.37.1445424850242; Wed, 21 Oct 2015 03:54:10 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id gl9sm9627968wjb.10.2015.10.21.03.54.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 03:54:09 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <562702C2.6070505@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:192343 Archived-At: On 10/21/2015 06:13 AM, Eric Ludlam wrote: > 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. If CEDET support won't improve Robe, and if the said support will amount to writing a Wisent grammar, it just becomes a separate task. Which I don't object to doing, in principle, but it'll go to the bottom of the pile, in terms of priority. > 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 both cases, I often have to prompt the user (with completing-read) to disambiguate between classes that define the method with the given name. > 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. So as faux tags, I could return all methods with the same name from different classes? > This would enable Semantic's jump to tag system to be as accurate as yours. Would that be semantic-complete-jump or semantic-ia-fast-jump? > 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. It's a struct, containing both the arguments list, and a doc string. I display it specially, though: do a little lightweight parsing, and highlight the Ruby examples parts with ruby-mode font-lock rules, and C sources with c-mode. Plus highlighted function signature at the top and a button to go to the source. > 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. ruby-add-log-current-method is the value of add-log-current-defun-function, but I don't know if you'd be able to use it for different languages: the format doesn't seem to be particularly standardized. > An EDE type project for ruby (whatever that looks like) would provide a > place to hang project specific REPL buffers as needed. How? Using which major mode? I current use inf-ruby for that (not available in Emacs, for copyright assignment reasons). So it seems I'd have to add multi-REPL support for it first. The conceptually hard question is what do you do with external files that can be referenced from different projects? Suppose you have two open projects, each with its own REPL, you made a jump to an external file from project1. The you want to "jump to definition" on some method call in there. How do you pick the right REPL to ask for info? Suppose, after the first jump, you saved the reference to the right project in a buffer-local variable, so you can refer to it for the second jump. What if I want to do the next jump not from the same exact file, but from its neighbor? As a user, I can be confident that both files must be referenced by the project, but there will be no buffer-local value to use. Finding an idiomatic approach to that would be great. >> - 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. I don't know how much work would that be. Ruby doesn't have anything close to official, up-to-date BNF grammar. And it's pretty complex. At the moment, I'm doing context parsing in Elisp, so fix for the "trivial opportunities" might also be in Elisp, at first, with a few simple regexp searches. However, I'm seriously considering moving that part (and more) to Ruby, so that authors of integration with other editors won't have to redo that work: - There's a feature request for Vim support. - Someone actually implemented an Atom plugin already (not at all popular so far, but that doesn't matter). I'd also be able to reuse an existing parser. There is one that's been gaining in popularity over the last years. > 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. Since that grammar has been outside of Emacs for so long, I always assumed that the author vanished, and obtaining the release is impossible.