[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: joakim
Subject: Re: IDE
Date: Tue, 03 Nov 2015 12:54:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eric Ludlam <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]