klaus.berndl | 14 May 10:36 2007
Picon

Re: methods buffer

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
(Continue reading)

Perry Smith | 14 May 14:23 2007

Re: Cedet?

Hi Klaus,

I'm pretty busy as well.  I keep hoping my new company that sells disk drives will take off -- plus I have a full time job.

But, I *think* it sounds pretty simple.  So, like you, I can't promise but I'll try to fit that in.

Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems


On May 13, 2007, at 9:53 AM, <klaus.berndl <at> sdm.de> <klaus.berndl <at> sdm.de> wrote:

Hi,

i will take a look at your changes... but you have already found the problem ;-)
currently all "normal" keys are rebound for immediately doing an incremental and smart search in a tree-buffer ....and you said, this is a good idea :-)

maybe the best way would be to simulate something like C-s (incr. search in a normal emacs-buffer):
- in standard-mode a tree-buffer doesn't rebind anything for searching
- C-s in a tree-buffer switches on the tree-buffer-incremental-search and RET or C-q (as with normal C-s)
  switch off the tree-buffer-incremental-search...

Or even better: C-s in a tree-buffer runs the standard-Emacs-incremantal-search and C-S (Ctrl-Shift-s) runs the speacial tree-buffer-incr-search.

And even more better: lets make customizable the whole bunch, i.e. introducing a new ECB-option which allows to switch between
a) the current behavior where hitting normal-keys runs immediately in the tree-buffer-incr-search
b) C-s switches on the tree-buffer-incr-search
c) C-s does normal Emacs-incr-search and C-S switches on the tree-buffer-incr-search

What do you think?

Perry, are you willing to implement something like this? Unfortunately i'm really really busy but i could point you to the right entry points in the tree-buffer.el-code and also in the code of ecb-common-browser.el...

Anyway, what do you think, could this be a good approach?

Ciao,
Klaus


-----Ursprüngliche Nachricht-----
Von: ecb-list-bounces <at> lists.sourceforge.net im Auftrag von Perry Smith
Gesendet: Sa 12.05.2007 15:40
An: James Reeves
Cc: ecb-list <at> lists.sourceforge.net
Betreff: Re: [ECB-list] Cedet?

On May 5, 2007, at 9:30 AM, James Reeves wrote:

> Perry Smith wrote:
>>
>> Also, I am not sure if this mailing list is 'active'.  I've only seen
>> questions -- no answers.  But... what the hell.  Post your questions,
>> see what happens.
>>
> That's a shame, as I just joined to ask some questions as well! Looks
> like I'm going to be on my own, but perhaps I should try: has 
> anyone had
> any luck changing the key bindings for the tree buffer mode? I tend to
> use the "jkl;" keys for navigation (well, "htns", since I use the 
> Dvorak
> layout), but the tree buffer in ecb appears to be hard-coded for use
> with the arrow keys. Is there any way of convincing it to change it's
> behaviour?

Attached is a diff of tree-buffer.el  I am using the svc (cvs?) 
version.  It is not much of a change.

I took the single tree-buffer-arrow-pressed and broke it up into four 
separate functions: tree-buffer-up-arrow-pressed, down, left, and 
right.  There is not that much duplicate code.  I then changed the 
key map to call these routines directly.

It is now possible to hook up the keys that you want to these 
routines.  It sounds like James knows how to do that part of it.  I 
was going to do that also but discovered that the keys default to 
doing a search -- which seems like a really good idea.

Good luck... have fun...
Perry Smith ( pedz <at> easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems



-------------------------------------------------------------------------
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/
_______________________________________________
Ecb-list mailing list
Ecb-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecb-list
klaus.berndl | 14 May 15:36 2007
Picon

Re: methods buffer


 <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/
Oviedo Javier-PKJ843 | 14 May 16:39 2007

mouse button bindings

Hello Klaus, et. al.
 
I'd like to modify the way ECB treats mouse buttons in the History, Methods buffer, etc. In the speedbar window, within ECB, double clicking on a file or directory tree performs the same function as hitting return from the keyboard (ie. opening/closing the directory, jumping to that file, etc.) I'd like to be able to extend the same "double-click" capability to other ECB windows.
 
Is this possible/customizable?
 
Thanks.
Javier
 
-------------------------------------------------------------------------
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/
_______________________________________________
Ecb-list mailing list
Ecb-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecb-list
klaus.berndl | 14 May 18:07 2007
Picon

Re: mouse button bindings

probably yes - but as in a previous posting described, the whole binding is currently hard-coded... but yu are right, the keybindings of a tree-buffer should be customizable... currently they are only overrideable via the tree-buffer hooks... not really a good approach...
 
Klaus

From: ecb-list-bounces <at> lists.sourceforge.net [mailto:ecb-list-bounces <at> lists.sourceforge.net] On Behalf Of Oviedo Javier-PKJ843
Sent: Monday, May 14, 2007 4:39 PM
To: ecb-list <at> lists.sourceforge.net
Subject: [ECB-list] mouse button bindings

Hello Klaus, et. al.
 
I'd like to modify the way ECB treats mouse buttons in the History, Methods buffer, etc. In the speedbar window, within ECB, double clicking on a file or directory tree performs the same function as hitting return from the keyboard (ie. opening/closing the directory, jumping to that file, etc.) I'd like to be able to extend the same "double-click" capability to other ECB windows.
 
Is this possible/customizable?
 
Thanks.
Javier
 
-------------------------------------------------------------------------
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/
_______________________________________________
Ecb-list mailing list
Ecb-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecb-list
Eric M. Ludlam | 14 May 22:40 2007

Re: [CEDET-devel] methods buffer

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/

Gmane