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, 28 Oct 2015 04:16:37 +0200 Message-ID: <56303005.4030808@yandex.ru> References: <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> <56276ECE.3090508@yandex.ru> <56281747.9050305@gmail.com> <56282664.3000409@yandex.ru> <56283D79.2070904@gmail.com> <5628C5E7.5060803@yandex.ru> <5628DD6C.6000408@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 1445998618 25689 80.91.229.3 (28 Oct 2015 02:16:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Oct 2015 02:16:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eric Ludlam , David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 28 03:16:53 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 1ZrGIE-0002aM-JX for ged-emacs-devel@m.gmane.org; Wed, 28 Oct 2015 03:16:50 +0100 Original-Received: from localhost ([::1]:35237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrGID-0005AW-RW for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 22:16:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrGIA-00059k-L7 for emacs-devel@gnu.org; Tue, 27 Oct 2015 22:16:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrGI5-0006oB-LI for emacs-devel@gnu.org; Tue, 27 Oct 2015 22:16:46 -0400 Original-Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:34118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrGI5-0006o5-Eo for emacs-devel@gnu.org; Tue, 27 Oct 2015 22:16:41 -0400 Original-Received: by wikq8 with SMTP id q8so236057950wik.1 for ; Tue, 27 Oct 2015 19:16:40 -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=cuuudQFOsgXTLYQK8RxCLyXv9DtPWqFjl4CwCf6kPRM=; b=lbgNs/ckrC7tDZic6HCSwB4H3ue4zN5FnJyJwM4gIr87rY3ifMy9LePqgHS3iz7TZ2 3ipXgKoyJ+r5KRa2sJWf0xgsxs62kw/gfhJdoM+yoL+NY+IMT0LvDjsHeF62B3WB4nej mUWoGT6/gLZdO0fbB8pM01D63qn5dXSCOIqKVo5DsZYrzUu6prBSN643pjOqO8zNruPX FOGKmSO0nbf8pjYN0BC6JDUVBJYRXMAicrw1pbjR8ey1kT/tjmguQmWxIDK5UxcPoJtV p2N33YcvWckXrblxQJSmJJ7emJXuseTJB6eM/AeeLvLf8OFYn5CiVuGoB1ncNakZrt2w TNuQ== X-Received: by 10.180.188.134 with SMTP id ga6mr319765wic.34.1445998600806; Tue, 27 Oct 2015 19:16:40 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id q11sm25598157wik.1.2015.10.27.19.16.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2015 19:16:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <5628DD6C.6000408@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::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:192768 Archived-At: On 10/22/2015 03:58 PM, Eric Ludlam wrote: > Semantic's idle process handling makes sure databases are synchronized > once, then enables tools to run after, so it is more about the > scheduling of different tools that use semantic. Cool. But I guess we could just say I was thinking of 'semantic-idle-summary-idle-function, and not semantic-idle-summary-mode itself. > In addition, by going through the semantic version, there are a range of > different formatting options to use that the user can select from. That > doesn't require idle-summary-mode, but is a side effect of using > semantic to extract contextual information. The formatting options depend on using some rich structure like Semantic tags. So it would make sense to port that only after we standardize on some tag format universally across Emacs (are Semantic tags optimal? I don't know). > It was deemed optional when Yidong merged CEDET into Emacs. You will > probably need to use Emacs24 to make it work. To try it out do this: Step 6 is broken for me. > 1) Install graphviz (it uses that for the layout engine) > 2) Start emacs 24 > 3) Use CEDET from it's git repository > 4) M-x find-library RET cogre RET > 5) find cogre-element-peer in the code > 6) M-x cogre-uml-quick-class RET I only get a "Class:" prompt, without a default value or completions. Typing "cogre-element-peer" gives me "Could not find class ...", even though cogre is obviously loaded. That's in Emacs 24.5. > When thinking about CEDET, it isn't about a > bullet list of user facing features but about how it can enable someone > working on said feature to have their work leveraged to a wider audience. People working on said features should be encouraged, of course. Unfortunately, the two more interesting projects that I've seen utilize CEDET are language-specific: - SRefactor only does anything useful for C/C++. - Oleh Krehel's function-args even mentions C/C++ in its summary. Perhaps, if there were more broadly applicable examples, it would lead to broader adoption. Maybe we should wonder why prefer making tools for CEDET that only target C and C++.