Re: [CEDET-devel] methods buffer
Eric M. Ludlam <eric <at> siege-engine.com>
2007-05-14 20:40:35 GMT
Your descriptions are basically correct. One area of confusion for
Hadron is that when I suggested using ebrowse, I meant the semantic
integrated ebrowse, which allows BROWSE database files to form the
basis of a semantic tag database. This lets semantic use the fast C++
parser on system or project libraries in it's searches.
See semanticdb-create-ebrowse-database for a short description.
If I can rig faster parsing of large system library sets, and faster
searching, then semantic will be good-to-go for intellisense like
things. For refactoring, cogre will eventually be a graphical UI for
building or modifying objects, and srecode will be the basis for code
generation. I need to get the intellisense working better first
through.
If anyone has time to spend on these projects, please let me know.
Thanks
Eric
>>> <klaus.berndl <at> sdm.de> seems to think that:
>
> <at> Eric: please correct me if i have written nonsense below.... 
>
>
>Hadron wrote:
>> This is such a shame.
>>
>> It is almost there. if only CEDET would do what eclipse does and cache
>> included files too it would be superior to eclipse since its in emacs
>> :)
>>
>> I just retried CDT in eclipse and it is excellent.
>>
>> I cant see an option to "re-cache" included files to be so tricky for
>> cedet/semantic. And to show "locals".
>
>all this stuff is completely cedet-depended so probably Eric etc. can give yu best
>information what is a) currently possible/supported and b) supported in near
>future and c) probably never supported ...
>
>>
>> Unfortunately cedet/semantic is pretty tricky stuff to setup and use
>> IMO and the maintainer has indicated that he, unfortunately, doesnt
>> have the necessary time to make the improvements and bug fixes he
>> would like.
>>
>> One of the major issues is that there is big confusion as to what the
>> different things do. e.g tags, etags, semantic navigation, cscope. I
>> asked about what semantic-navigation did and why it didnt work between
>> files and was told to use ebrowse - but my understanding is that
>> ebrowse is for c++ and not C. Fortunately cscope does a good job, but
>> its "yet another" package.
>
>a try:
>
>a tag: just a name for one lexical and/or semantic token in a language
> (e.g. a variable, a method-definition, an include-operator etc. etc.).
> a tag contains several informations, at least the name of the tag
> (i.e. the name of the variable, class, method....) and the locations
> of this tag in the buffer (ie. begin- and end-position) and probably
> also the file-name the tag belongs to....
>
>semantic: part of the cedet-suite and a lexical and syntactical parser
> based on emacs-lisp (as yacc/bison based on c). Currently semantic consists
> of a general backbone and several-parsere for each supported languages (as
> emacs-lisp itself, java, c, c++ etc.). semantic offers several interfaces
> (elisp-functions) to get parsing-informations about the currently parsed
> file/buffer. The output is either a single tag (e.g. semantic has a function
> which gives you the tag at point) or a list of tags (e.g. "give me all
> tags in the current buffer). For the term 'tag' see above...
>
>cedet: contains the semantic-parser itself and a lot of necessary additional
> functionality to use the tag-lists. cedet contains not only the semantic parser
> but also the speedbar which is a displayor of the tag-lists returned by either
> the semantic-parser or the etags/imenu-stuff (s.b.) In addition speedbar contains
> also a file-directory-browser and displays its contents in a separated frame.
>
>etags: an external commandline-program which supports parsing a lot
> of languages and writes a a file containing all tags of the parsed file.
> these tags have other structure as the tags returned by semantic but in general
> etags gives also a list of tags. Emacs offers an elips-interface to a) run
> the etags-program and b) read the written tag-file to work with tags
>
>imenu: imenu.el is a special-emacs-library which returns also a list of tags of
> the current buffer. again different tag-format but in general a list of tags
> in the sense described above.
>
>ebowse: is a somehow clumsy mixture consisting of a fast(!) c++-parser combined
> with some displaying/navigating features and is part of Gnu Emacs >= 21.... it's not
>written in elisp but in c - at least the parser-core and has an elisp-interface giving
>access to the tags (which reside in an extrenal file similar to the etags approach)
>
>ECB: is a displayor of the tag.stuff offered either by semantic, imenu or etags.
> Best supported are tags returned by the semantic-parser. It has a own window-layout
> engine as described in my previous email.... in general white similar to the speedbar
> but with a complete different approach to display all the stuff. To make the confusion
> complete: You can customize ECB so it displays a speedbar in one of its special windows.
> This comes from a suggestion that some people like the tag-display of ECB but like
> also the directory/files-display of the speedbar and vice versa...
>
>ECB (and also speedbar) is really great in displaying the tag-content of the current
>file/buffer to navigate between the different contents (methods, variables, classes etc..)
>in a buffer via mouse-clicking onto the displayed tag in the browsing windows.
>
>But The support of browsing a huge code-base spliited in hundreds of different files
>is still somehow clumsy (switching between the .h and .ccp files for example is supported)
>and IMHO to really smart.... in general: give the user fast and comfortable access to all
>accessible tags (methods, classes etc..) of a whole code-base is still not really good - at
>least AFAIK - but i saw also in the mailing lists of cedet, that Eric has done great job
>in imporving this........AFAIK cedet now can enable access to an ebroswe-tag-file (in general
>to any arbitrary backend containing tags in any arbitrary tag-format) and offers an interface
>to convert these ebrowse-tags in semantic-tag-format.. so semantic (and ECB) can take advantage
>from the ebrowse-program which is really fast in parsing a huge code-base of c++-code.
>AFAIK all this new stuff is great but still in beta-stadium... but ask cedet about the
>correct status...
>
>cscope: i do not know this one............
>
>To make a long story short: ECB is a displayor of tags provided by a parsing engine
>like semantic, imenu and etags... all Tags accessible through any of these interfaces
>can be displayed by ECB - and because now semantic offers a general interface to access
>arbitryray tag-backends and to convert them in the semantic-tag-format ECB automaticaly
>benefits from this too.
>
>>
>> Semantic/ecb is so close to be being really good, but I have a feeling
>> from polling a few programmers that no one is really using it in the
>> real world - or not enough to generate enough momentum to make it
>> worthwhile for people to maintain :(
>>
>
>hmm, yes, see my honest judgement about the future of Emacs in general concerning
>professional programming in current technologies as java, c# and c++ - IMHO an IDE
>like Eclipse (which is now really good) or IntelliJ or Visual Studio beats Emacs
>(even when running cedet and ecb) cause of much better refactoring (most important),
>Intellisense and speed... and e.g. Eclipse offers also a very good plugin-interface and
>therefore support for quite everything a user can imagine...
>
>I admit the pure editing capabilities of Emacs are much(!!) better than that of Eclipse etc..
>but this is not so important than a good refactoring and Intellisense support - at least
>when efficieny and cost-awareness are important criteria... and Eclipse is also for free...
>so currently i see really not many advantages of Emacs compared to Eclipse...
>
>But each programmer should use the tool he likes most - but not only "like a tool" is
>important, to work as efficient as possible is even more important, at least in the
>hard world of business ))
>
>Hope, my short description of several terms (s.a.) is somehow helpful for you....
>
>Klaus
>
>> thanks for your polite reply.
>>
>>
>>
>> <klaus.berndl <at> sdm.de> writes:
>>
>>> Hi,
>>>
>>> no, you haven't miss...
>>>
>>> This is not an ECB-question but an cedet-question but i can also
>>> give you a hint:
>>> Currently cedet does no "local"-parsing just object_, struct-,
>>> class-, methods/function- and "file"-global(!) variable-defintions
>>> are parsed and therefore shown in the methods-buffer. With java also
>>> local-parsing is possible, IIRC... but please ask the cedet-gurus...
>>>
>>> Please remember: ECB does no parsing for itself, it isn't more than
>>> a "dumb" "Displayor" of the parsing result of the underlying
>>> parsing.engine, which can be (at the moment):
>>> - cedet (supported as best as possible)
>>> - imenu and etags (via the speedbar-interface for these two parsers):
>>> supported by ECB for languages not supported by a cedet-parser.
>>>
>>> ECB is responsible to give a user an IDE-feeling concerning
>>> window-layout etc.... it's more or less a different approach than
>>> the speedbar for people who doesn't like separate frames but one
>>> single frames with some special windows (at left, right or top of
>>> the frame, depending on the ecb-layout you use) and offers for the
>>> remaining editing-area the feeling to work with a "normal"
>>> Emacs-frame without special windows (i.e. all commands like C-x 1,
>>> C-x 2 etc... in general all window-changing/navigating commands
>>> should not affect the special browsing windows. On top there is an
>>> (optional) compile-output-window at the bottom - also not (or smart)
>>> affected by such commands.... with XEmacs and forthcoming Emacs 22
>>> also nice icon-display in the tree-buffers is possible, for the look
>>> and feel...
>>>
>>> Current lacks of ECB:
>>> - no project support as known from IDEs like IntelliJ or Eclipse or
>>> Visual studio - maybe the EDE (shipped with cedet) sould be a way...
>>> - no generic interface to arbitrary parsers - currently only cedet,
>>> imenu and etags are supported.
>>> - ...
>>> - (probably the most heavy drawback): No really good support of
>>> refactoring - ECB runs well with xRef (so maybe this culd be way),
>>> but hmm...............
>>> - (a cedet drawback): Still no really good IntelliSense (but IIRC,
>>> Eric and cedet have worked hardly to imporve this but i do not know
>>> the most recent cedet)
>>>
>>> I know the limitations of ECB and also the - sometimes hard to
>>> detect - interfaces/differences between ECB and cedet (just see
>>> cedet as information supporter of parsing-informations and ECB as
>>> the Displayor of all this parsing stuff - with an attachted
>>> file-browser and buffer-history ...
>>>
>>> probably the approach "Offering a graphical IDE on Emacs-basis" will
>>> have no future, because Emacs is not designed to run with such a
>>> window-layout-manager as ECB is. ECB need thousands of lines of code
>>> to advice standard-Emacs-functions/commands to work comfortable and
>>> smart with such a window-layout.... IMHO ECB does currently a good
>>> job with this respect but is also limited ........... IMO the
>>> following is fact: A combination of Emacs/ECB/cedet can *never* be
>>> as good as a professional IDE as Eclipse or IntelliJ. Please do not
>>> misunderstand me: Emacs is great editor (the best editor available),
>>> but for serious professional programming with a huge code-basis you
>>> need an IDE such as Eclipse or IntelliJ (for java) to work as
>>> efficient as possible - IMHO for professional programming the best
>>> available IntelliSense- and refactoring- and project-support is a
>>> MST and much more important than some pure-editing-goodies as Emacs
>>> offers for editing.
>>>
>>> Well, no i have argumented against my own ECB ) But i want to be
>>> honest: Emacs is great, cedet and ECB are alos great and show what
>>> is possible with elisp and Emacs but i doubt that they can compare
>>> in future with stuff like Eclipse and IntelliJ (and also Visual
>>> Studio which is quite a must for serious .NET and
>>> c#-programming)....
>>>
>>> Just my humble opinion... 
>>>
>>> Ciao,
>>> klaus
>>>
>>> Hadron wrote:
>>>>> From reading the documentation I expected the methods buffer to
>>>>> show
>>>> variables too. It doesnt seem to. Have I missed how to enable this?
>>>>
>>>> I am using emacs 23, ecb-snapshot and cvs cedet.
>>>>
>>>> e.g Here in this test case I see main() and f(), but I expected to
>>>> see the variables a,b,c and fedora too.
>>>>
>>>>
>>>> ,----
>>>>> #include <fstab.h>
>>>>> #include <asm/thread_info.h>
>>>>>
>>>>> int main()
>>>>> {
>>>>> struct t {
>>>>> int a;
>>>>> float b;
>>>>> double c;
>>>>> }
>>>>>
>>>>> f(1);
>>>>>
>>>>> int a=3,b=2;
>>>>> int c=f();
>>>>>
>>>>> struct fstab fedora;
>>>>>
>>>>> fedora.fs_file=1;
>>>>> fedora.fs_passno=1;
>>>>> fedora.fs_file=3;
>>>>> fedora.
>>>>> }
>>>>>
>>>>> int f(int a){
>>>>> return ++a;
>>>>> }
>>>> `----
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Cedet-devel mailing list
>Cedet-devel <at> lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
RSS Feed