From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 03 Nov 2015 12:54:49 +0100 Message-ID: References: <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> <56303005.4030808@yandex.ru> <5630B405.40007@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446551743 26603 80.91.229.3 (3 Nov 2015 11:55:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 11:55:43 +0000 (UTC) Cc: emacs-devel@gnu.org, David Engster , Dmitry Gutov To: Eric Ludlam Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 03 12:55:30 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 1ZtaBV-0000DC-I7 for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 12:55:29 +0100 Original-Received: from localhost ([::1]:47341 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtaBV-0000ML-2Y for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 06:55:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtaBH-0000ME-7v for emacs-devel@gnu.org; Tue, 03 Nov 2015 06:55:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtaBE-0000oF-1O for emacs-devel@gnu.org; Tue, 03 Nov 2015 06:55:15 -0500 Original-Received: from mx6.bahnhof.se ([213.80.101.16]:52210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtaBD-0000o2-Lo for emacs-devel@gnu.org; Tue, 03 Nov 2015 06:55:11 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx6-reinject (Postfix) with ESMTP id 0124B41A5E; Tue, 3 Nov 2015 12:55:08 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF2) Original-Received: from mf2.bahnhof.se ([127.0.0.1]) by localhost (mf2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-zcWEI7w7K5; Tue, 3 Nov 2015 12:55:01 +0100 (CET) Original-Received: from mta.verona.se (h-235-62.a149.priv.bahnhof.se [85.24.235.62]) by mf2.bahnhof.se (Postfix) with ESMTP id DC3B0940111; Tue, 3 Nov 2015 12:55:00 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 61AB54EDA3E; Tue, 3 Nov 2015 11:55:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cbqtusWq2JQ; Tue, 3 Nov 2015 12:54:49 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id CE0A84EDA3C; Tue, 3 Nov 2015 12:54:49 +0100 (CET) In-Reply-To: <5630B405.40007@gmail.com> (Eric Ludlam's message of "Wed, 28 Oct 2015 07:39:49 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 213.80.101.16 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:193137 Archived-At: Eric Ludlam writes: > On 10/27/2015 10:16 PM, Dmitry Gutov wrote: >> On 10/22/2015 03:58 PM, Eric Ludlam wrote: >> >>> 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). >> > > What is optimal? For me, it was about pulling all the datatype > information out of the syntax, and differentiating between different > tag classes, and having something that was Emacs friendly, and > extensible to any language, no matter how strange. For me, Semantic's > tag structure is pretty good. It has 5 slots: > > * The name, as 'car' so you can use assoc and other friendly things. > * The class of the tag is next, as all languages have different kinds > of tags. > * plist of attributes, extensible to use anything, but with some > common attribute names defined for use via API. > * plist of properties, or bits of data needed by the tooling, which is > arbitrary and extensible for whatever a tool might need. > * Buffer binding information - either the [start end] of the tag, or > an overlay. > > That makes the tag extensible for almost any situation, and keeps TAG > data and OPERATIONAL data separate, saveable, and searchable. > >>> 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. > > Did you enable semantic-mode? The buffer would need to be parsed for > the data to be available, and for the prompt to have completion. > >>> 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. I'm not sure this is related, but I've done many little project specific tools using parts of Cedet. For instance SRecode, and Cogre, and Semantic. Since the things I made were tools for one-off tasks, I didn't bother to publish them. I think a lot of use-cases are like this, and a lot of people use various parts of Cedet like this. Now you will say that this is a thread about making an IDE, but I still think this use-case deserves mentioning. >> >> 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++. >> . > > This is a good point. I always have thought about language > independence and extensibility, but most folks are just trying to > solve a problem and may not be interested in extending to anything > else. > > I've built many little tools over the years, but perhaps they are > observed as parts of CEDET core, and not as examples. The semantic-ia > functions were supposed to be examples for how to use the > infrastructure, but users have ended up using them as their interface > and they became more complex. > > Eric > > -- Joakim Verona