Thread: Re: [CEDET-devel] [ECB-list] methods buffer
Brought to you by:
zappo
From: <kla...@sd...> - 2007-05-14 13:36:49
|
@Eric: please correct me if i have written nonsense below.... ;-) Hadron wrote: > This is such a shame. >=20 > 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 > :)=20 >=20 > I just retried CDT in eclipse and it is excellent. >=20 > 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 ... >=20 > 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.=20 >=20 > 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 >=3D = 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=20 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=20 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. >=20 > 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 :( >=20 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. >=20 >=20 >=20 > <kla...@sd...> writes: >=20 >> Hi, >>=20 >> no, you haven't miss... >>=20 >> This is not an ECB-question but an cedet-question but i can also >> give you a hint:=20 >> 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... >>=20 >> 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): =20 >> - 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. >>=20 >> 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... ;-) =20 >>=20 >> 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...=20 >> - no generic interface to arbitrary parsers - currently only cedet, >> imenu and etags are supported.=20 >> - ... >> - (probably the most heavy drawback): No really good support of >> refactoring - ECB runs well with xRef (so maybe this culd be way), >> but hmm............... =20 >> - (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) =20 >>=20 >> 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 ... =20 >>=20 >> 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. =20 >>=20 >> 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).... =20 >>=20 >> Just my humble opinion... :-) >>=20 >> Ciao, >> klaus >>=20 >> Hadron wrote: >>>> From reading the documentation I expected the methods buffer to >>>> show=20 >>> variables too. It doesnt seem to. Have I missed how to enable this? >>>=20 >>> I am using emacs 23, ecb-snapshot and cvs cedet. >>>=20 >>> 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. >>>=20 >>>=20 >>> ,---- >>>> #include <fstab.h> >>>> #include <asm/thread_info.h> >>>>=20 >>>> int main() >>>> { >>>> struct t { >>>> int a; >>>> float b; >>>> double c; >>>> } >>>>=20 >>>> f(1); >>>>=20 >>>> int a=3D3,b=3D2; >>>> int c=3Df(); >>>>=20 >>>> struct fstab fedora; >>>>=20 >>>> fedora.fs_file=3D1; >>>> fedora.fs_passno=3D1; >>>> fedora.fs_file=3D3; >>>> fedora. >>>> } >>>>=20 >>>> int f(int a){ >>>> return ++a; >>>> } >>> `---- |
From: Eric M. L. <er...@si...> - 2007-05-14 20:40:45
|
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 >>> <kla...@sd...> seems to think that: > >@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. >> >> >> >> <kla...@sd...> 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 >Ced...@li... >https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Maciej K. <mat...@gm...> - 2007-05-14 23:55:21
|
Den Mon, 14 May 2007 16:40:35 -0400 skrev Eric M. Ludlam: > 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. I don't have the time right now, but I expect to have it fairly soon, and fully intend to spend it on CEDET hacking. I want to tackle Intellisense first (I've already started, see the (very buggy right now) sematic-hover-completion.el, version 0.1 of which I posted on emacs-sources), then IDE-like project management, then I wanted to look into refactoring and more advanced tricks with semantic. In the end, I want to make a package that combines all the helpers into something that would be easy to setup, without requiring all the piecing together work needed right now, yet flexible enough not to get too much into the normal emacs way of doing things. Making it fast is not entirely undesirable, either, especially for the intellisense bit. Cheers, Maciej |
From: Eric M. L. <er...@si...> - 2007-05-15 01:52:36
|
>>> Maciej Katafiasz <mat...@gm...> seems to think that: >Den Mon, 14 May 2007 16:40:35 -0400 skrev Eric M. Ludlam: > [ ... ] >> If anyone has time to spend on these projects, please let me know. > >I don't have the time right now, but I expect to have it fairly soon, and >fully intend to spend it on CEDET hacking. I want to tackle Intellisense >first (I've already started, see the (very buggy right >now) sematic-hover-completion.el, version 0.1 of which I posted on >emacs-sources), then IDE-like project management, then I wanted to look >into refactoring and more advanced tricks with semantic. In the end, I >want to make a package that combines all the helpers into something that >would be easy to setup, without requiring all the piecing together work >needed right now, yet flexible enough not to get too much into the normal >emacs way of doing things. Making it fast is not entirely undesirable, >either, especially for the intellisense bit. [ ... ] That sounds great. I haven't read gnus in a long time... around the time I was forced to start using Outlook for mail at work. Ugh. If there is some other place to get see your hover completion, let me know. After my last spate of fixing intellisense bugs, I now find most of my time is spent on figuring out how to find and search databases, and how to transparently create and manage them. The problem results in unfindable symbols, and no intelli. A side effect of that is a bunch of doc that can't keep up with the code. Anyway, cedet has a baseline for all the items you list. Keep the mailing list up to date. I'll be happy to integrate any bug-fixes you discover. Good Luck Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |