Thread: [jdee-devel] functionality development
Brought to you by:
paullandes
From: Thomas F. <tfi...@fc...> - 2008-11-20 09:38:11
|
Hi a couple of quick questions about functionality development in jdee. Question 1: The website states that jdee is a tool that integrates third party tools into emacs for java development. What does that mean? - Does it mean that the third party packages provide complete functionality that jdee interfaces or - does it mean that jdee uses those third party packages to put together a range of complete functionalities which did not previously exist. The reason for the question is that I would like to help develop some functionality for jdee, and I was thinking was to use perl to create the functionality and then lisp code to integrate it into jdee. Question 2: What kind of tags program/functionality does jdee support or exists in jdee? I have been using the standard ctags/etags program and the standard emacs tags functionality. But for java development it seems to lack some features which make it more efficient. For example, a tag search does not seem to take context of a method call into consideration. This means all possible getX() methods in the source code is visited, one after another. What it should do is: if the method call is prefixed with an instance reference or class name, it should start the search in that class and expand outwards as appropriate. It shold not f.ex. start in the class that is alphabetically first in the tags list. Other things i feel is missing is that searches should differentiate between interfaces and classes, one implementation of an interface from another (in f.ex. a separate package) and so on If there is no tags program or emacs functionality to support this I would like to help by developing this, I just need to know what is the preferred approach to extend functionality. regards thomas |
From: Paul L. <la...@ma...> - 2008-11-20 15:25:11
|
Thomas, There are currently many outstanding issues in JDEE that are currently being address. Unfortunately due to where the project is and the limited time of the few developers working on the project, there is no release out yet and won't be until it's in a good enough position to have a release. Everyone has and is making due with the release put out a while ago. Only after all the (large number mind you) patches are integrated will we put out the release. Once this is done, notification of this will be put out to the list and then we'll begin the normal development life cycle once more. Thomas Finneid writes: > Hi > > a couple of quick questions about functionality development in jdee. > > Question 1: > > The website states that jdee is a tool that integrates third party tools > into emacs for java development. What does that mean? > > - Does it mean that the third party packages provide complete > functionality that jdee interfaces or > - does it mean that jdee uses those third party packages to put together > a range of complete functionalities which did not previously exist. > > The reason for the question is that I would like to help develop some > functionality for jdee, and I was thinking was to use perl to create the > functionality and then lisp code to integrate it into jdee. > > Question 2: > > What kind of tags program/functionality does jdee support or exists in jdee? > > I have been using the standard ctags/etags program and the standard > emacs tags functionality. But for java development it seems to lack some > features which make it more efficient. > > For example, a tag search does not seem to take context of a method call > into consideration. This means all possible getX() methods in the source > code is visited, one after another. What it should do is: if the method > call is prefixed with an instance reference or class name, it should > start the search in that class and expand outwards as appropriate. It > shold not f.ex. start in the class that is alphabetically first in the > tags list. Other things i feel is missing is that searches should > differentiate between interfaces and classes, one implementation of an > interface from another (in f.ex. a separate package) and so on > > If there is no tags program or emacs functionality to support this I > would like to help by developing this, I just need to know what is the > preferred approach to extend functionality. > > > regards > > thomas > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel -- Paul Landes la...@ma... |
From: Phillip L. <phi...@ne...> - 2008-11-20 17:23:13
|
Thomas Finneid <tfi...@fc...> writes: > a couple of quick questions about functionality development in jdee. > > Question 1: > > The website states that jdee is a tool that integrates third party tools > into emacs for java development. What does that mean? > > - Does it mean that the third party packages provide complete > functionality that jdee interfaces or > - does it mean that jdee uses those third party packages to put together > a range of complete functionalities which did not previously exist. More the latter. JDE doesn't compile java, but does run javac. Likewise, ant and (I think) mvn and so on. Add all the standard emacs stuff (like version control support) and you have a development environment. > > The reason for the question is that I would like to help develop some > functionality for jdee, and I was thinking was to use perl to create the > functionality and then lisp code to integrate it into jdee. That would work; however, because you'd have to use the perl as an external command, the integration with emacs might not be as good as if you did it in lisp. Whether or not this is a problem depends on what you are trying to do. > What kind of tags program/functionality does jdee support or exists in jdee? > > I have been using the standard ctags/etags program and the standard > emacs tags functionality. But for java development it seems to lack some > features which make it more efficient. > > For example, a tag search does not seem to take context of a method call > into consideration. This means all possible getX() methods in the source > code is visited, one after another. What it should do is: if the method > call is prefixed with an instance reference or class name, it should > start the search in that class and expand outwards as appropriate. It > shold not f.ex. start in the class that is alphabetically first in the > tags list. Other things i feel is missing is that searches should > differentiate between interfaces and classes, one implementation of an > interface from another (in f.ex. a separate package) and so on > > If there is no tags program or emacs functionality to support this I > would like to help by developing this, I just need to know what is the > preferred approach to extend functionality. > There are a couple of things there. JDEE used to provide etags support for java. I don't think that it needs this any more as it's there by default. Gnu Global support would be nice to add; again I've not tried this. It's possible emacs support is already there. Finally, semantic builds a database which you can search. Again, not tried this. Sorry that this part of my answer is pretty useless; I tend to just grep when I need this functionality. Phil |
From: Eric M. L. <er...@si...> - 2008-11-20 19:05:46
|
>>> Phillip Lord <phi...@ne...> seems to think that: > > >Thomas Finneid <tfi...@fc...> writes: [ ... ] >> I have been using the standard ctags/etags program and the standard >> emacs tags functionality. But for java development it seems to lack some >> features which make it more efficient. >> >> For example, a tag search does not seem to take context of a method call >> into consideration. This means all possible getX() methods in the source >> code is visited, one after another. What it should do is: if the method >> call is prefixed with an instance reference or class name, it should >> start the search in that class and expand outwards as appropriate. It >> shold not f.ex. start in the class that is alphabetically first in the >> tags list. Other things i feel is missing is that searches should >> differentiate between interfaces and classes, one implementation of an >> interface from another (in f.ex. a separate package) and so on >> >> If there is no tags program or emacs functionality to support this I >> would like to help by developing this, I just need to know what is the >> preferred approach to extend functionality. >> [ ... ] >Sorry that this part of my answer is pretty useless; I tend to just >grep when I need this functionality. [ ... ] Semantic can find a tag based on code context accurately based on the object type in the code, not just on the name. For C++, it gets it right all the time. At least, in the code I've run it on. As I don't code in Java, I've not tested it there. If it doesn't work, the tweak needed would be very small. I've not worried much about the Java piece because I assumed the beanshell feature solved this issue already. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Paul K. <Pau...@ma...> - 2008-11-20 19:27:14
|
Eric is correct. The JDEE has had an intelligent, Java-aware completion facility for a long time, i.e., it is based on identifying the class of the object whose field or method you are attempting to complete, using Java inspection to find all the methods and fields defined or inherited by that class, and then providing you with the subset of those method and field names that complete the expression at point. See the documentation. Paul > -----Original Message----- > From: Eric M. Ludlam [mailto:er...@si...] > Sent: Thursday, November 20, 2008 2:06 PM > To: Phillip Lord > Cc: jde...@li... > Subject: Re: [jdee-devel] functionality development > > >>> Phillip Lord <phi...@ne...> seems to think that: > > > > > >Thomas Finneid <tfi...@fc...> writes: > [ ... ] > >> I have been using the standard ctags/etags program and the standard > >> emacs tags functionality. But for java development it seems to lack > some > >> features which make it more efficient. > >> > >> For example, a tag search does not seem to take context of a method > call > >> into consideration. This means all possible getX() methods in the > source > >> code is visited, one after another. What it should do is: if the > method > >> call is prefixed with an instance reference or class name, it should > >> start the search in that class and expand outwards as appropriate. > It > >> shold not f.ex. start in the class that is alphabetically first in > the > >> tags list. Other things i feel is missing is that searches should > >> differentiate between interfaces and classes, one implementation of > an > >> interface from another (in f.ex. a separate package) and so on > >> > >> If there is no tags program or emacs functionality to support this I > >> would like to help by developing this, I just need to know what is > the > >> preferred approach to extend functionality. > >> > [ ... ] > >Sorry that this part of my answer is pretty useless; I tend to just > >grep when I need this functionality. > [ ... ] > > Semantic can find a tag based on code context accurately based on the > object type in the code, not just on the name. For C++, it gets it > right all the time. At least, in the code I've run it on. > > As I don't code in Java, I've not tested it there. If it doesn't > work, the tweak needed would be very small. I've not worried much > about the Java piece because I assumed the beanshell feature solved > this issue already. > > Eric > > -- > Eric Ludlam: er...@si... > Siege: www.siege-engine.com Emacs: > http://cedet.sourceforge.net > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Thomas F. <tfi...@fc...> - 2008-11-21 08:36:54
|
Hi I know, but I was not asking about command completion though. I was asking about tags etc. which requires code parsing, in similar fashion to command completion. Eric mentioned BeanShell, I dont know much about it but maybe I misunderstood. regards thomas Paul Kinnucan wrote: > Eric is correct. The JDEE has had an intelligent, Java-aware completion facility for a long time, i.e., it is based on identifying the class of the object whose field or method you are attempting to complete, using Java inspection to find all the methods and fields defined or inherited by that class, and then providing you with the subset of those method and field names that complete the expression at point. See the documentation. > > Paul > >> -----Original Message----- >> From: Eric M. Ludlam [mailto:er...@si...] >> Sent: Thursday, November 20, 2008 2:06 PM >> To: Phillip Lord >> Cc: jde...@li... >> Subject: Re: [jdee-devel] functionality development >> >>>>> Phillip Lord <phi...@ne...> seems to think that: >>> >>> Thomas Finneid <tfi...@fc...> writes: >> [ ... ] >>>> I have been using the standard ctags/etags program and the standard >>>> emacs tags functionality. But for java development it seems to lack >> some >>>> features which make it more efficient. >>>> >>>> For example, a tag search does not seem to take context of a method >> call >>>> into consideration. This means all possible getX() methods in the >> source >>>> code is visited, one after another. What it should do is: if the >> method >>>> call is prefixed with an instance reference or class name, it should >>>> start the search in that class and expand outwards as appropriate. >> It >>>> shold not f.ex. start in the class that is alphabetically first in >> the >>>> tags list. Other things i feel is missing is that searches should >>>> differentiate between interfaces and classes, one implementation of >> an >>>> interface from another (in f.ex. a separate package) and so on >>>> >>>> If there is no tags program or emacs functionality to support this I >>>> would like to help by developing this, I just need to know what is >> the >>>> preferred approach to extend functionality. >>>> >> [ ... ] >>> Sorry that this part of my answer is pretty useless; I tend to just >>> grep when I need this functionality. >> [ ... ] >> >> Semantic can find a tag based on code context accurately based on the >> object type in the code, not just on the name. For C++, it gets it >> right all the time. At least, in the code I've run it on. >> >> As I don't code in Java, I've not tested it there. If it doesn't >> work, the tweak needed would be very small. I've not worried much >> about the Java piece because I assumed the beanshell feature solved >> this issue already. >> >> Eric >> >> -- >> Eric Ludlam: er...@si... >> Siege: www.siege-engine.com Emacs: >> http://cedet.sourceforge.net >> >> ----------------------------------------------------------------------- >> -- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Eric M. L. <er...@si...> - 2008-11-21 11:23:29
|
Could you explain in more detail what you want to do? The point of Semantic is to parse code at a detailed level, and provide tags that are not just a name, but name, parent class, inheritance type, arguments, datatype, and much more. Exuberant ctags can do the same. Eric >>> Thomas Finneid <tfi...@fc...> seems to think that: >Hi > >I know, but I was not asking about command completion though. I was >asking about tags etc. which requires code parsing, in similar fashion >to command completion. Eric mentioned BeanShell, I dont know much about >it but maybe I misunderstood. > >regards > >thomas [ ... ] -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Thomas F. <tfi...@fc...> - 2008-11-22 09:01:02
|
I feel there is important functionality missing in jdee. I am getting hammered almost every day by people at work who complain that I dont use Eclipse or IntelliJ, and they are to a certain extent right. Jdee is missing essential functionality, that would make me more productive. So what I want to do is implement the functionality I need to be more efficient. I havent any ide tools that much so I dont have a complete list of needed improvements, but the majort things my IDE must support is the following. First of all I want better documentation of jdee, so I would like to reorganise and update the documentation. Plus I want to make it w3c compatible, since it does not work in Opera and is a little outdated. If anybody has any input on that, please let me know. Here is a longer list of primary functionality I am missing. Some of it probably exists, but I have not found it yet and some things just dont exists in jdee yet. The basic stuff is the following: - Better access and overview of all resources included in a project: src files, test src, build scripts, config files, libraries etc. The Speedbar provides some of this but its not user friendly enough and does not include enough. - Essentially I want something like what eclipse has, the directory tree on the left side, which lists everything included in the project. It gives easy access to any resource in the project, independent of which directory its in and how complicated the name is. - Another solution could be something that search the entire project or something. - Better movement between buffers and resouces - In eclipse there are window panes, that allows you to easily find one of your many current windows. - In jdee there is only buffers and they have to be selected by typing the name of the buffer, every time you want to switch. it does not have a good history function so it takes up to 20 seconds to switch to another buffer than the previous one. - Better code completion, one that is faster, more accurate and, last but not least, more user-friendly. It should also support completing all included libraries etc. - Better compile cycle support, the whole code - compile - fix-bug - run cycle. It is probably there but I havent figured out how to set it up. The more advanced stuff is: - refactoring support, - mainly renaming and moving methods, attributes, - code wizards - which help automate creating classes for specific purposes in the program. I know there is some support for it, but I feel its not complete. - what I specifically want is a function that does all the mundane operations related to creating, or including, a class, adding it to the project, storing it in the right directory/package etc. etc. - additionally help create other mundane methods or classes one needs, e.g. enum classes, parameter classes etc. - javadoc access that works in all browsers finally I want all of this packaged into an install file that sets eveything up for me, easily, without a lot of reading and manual configuring. There is probably more but these are the most important things. regards thomas Eric M. Ludlam wrote: > Could you explain in more detail what you want to do? The point of > Semantic is to parse code at a detailed level, and provide tags that > are not just a name, but name, parent class, inheritance type, > arguments, datatype, and much more. > > Exuberant ctags can do the same. > > Eric > >>>> Thomas Finneid <tfi...@fc...> seems to think that: >> Hi >> >> I know, but I was not asking about command completion though. I was >> asking about tags etc. which requires code parsing, in similar fashion >> to command completion. Eric mentioned BeanShell, I dont know much about >> it but maybe I misunderstood. >> >> regards >> >> thomas > [ ... ] > |
From: poppyer <po...@gm...> - 2008-11-22 09:39:18
|
Some of your requirements can be accomplished by ECB. Although it is not prefect, but definitely worth trying. > > The basic stuff is the following: > > - Better access and overview of all resources included in a project: src > files, test src, build scripts, config files, libraries etc. The > Speedbar provides some of this but its not user friendly enough and does > not include enough. > - Essentially I want something like what eclipse has, the directory > tree on the left side, which lists everything included in the project. ECB's directory window can do this. > It gives easy access to any resource in the project, independent of > which directory its in and how complicated the name is. > - Another solution could be something that search the entire > project or something. > - Better movement between buffers and resouces > - In eclipse there are window panes, that allows you to easily find > one of your many current windows. > - In jdee there is only buffers and they have to be selected by > typing the name of the buffer, every time you want to switch. it does > not have a good history function so it takes up to 20 seconds to switch > to another buffer than the previous one. ECB's history window can do this. > - Better code completion, one that is faster, more accurate and, last > but not least, more user-friendly. It should also support completing > all included libraries etc. > - Better compile cycle support, the > whole code - compile - fix-bug - run > cycle. It is probably there but I havent figured out how to set it up. > > The more advanced stuff is: > > - refactoring support, > - mainly renaming and moving methods, attributes, > - code wizards > - which help automate creating classes for specific purposes in the > program. I know there is some support for it, but I feel its not > complete. > - what I specifically want is a function that does all the mundane > operations related to creating, or including, a class, adding it > to the project, storing it in the right directory/package etc. etc. > - additionally help create other mundane methods or classes one needs, > e.g. enum classes, parameter classes etc. > - javadoc access that works in all browsers > > finally I want all of this packaged into an install file that sets > eveything up for me, easily, without a lot of reading and manual > configuring. > > There is probably more but these are the most important things. > > regards > > thomas > > |
From: Len T. <len...@gm...> - 2008-11-22 20:50:20
|
Thomas Finneid wrote: > First of all I want better documentation of jdee, so I would like to > reorganise and update the documentation. Plus I want to make it w3c > compatible, since it does not work in Opera and is a little outdated. Sounds like a great idea, and a good way to start contributing to the project! > - In jdee there is only buffers and they have to be selected by > typing the name of the buffer, every time you want to switch. it does > not have a good history function so it takes up to 20 seconds to switch > to another buffer than the previous one. You might want to look into ido for souping up your regular buffer switching, and electric-buffer-list for letting you select buffers from a list of currently open ones -- both should let you get that 20 seconds way down :-). Cheers, Len. |
From: Phillip L. <phi...@ne...> - 2008-11-24 18:18:55
|
You're trying to do too much with JDEE and not enough with Emacs. A lot of this is very general and not specific to java. It's provide by other packages. Thomas Finneid <tfi...@fc...> writes: > First of all I want better documentation of jdee, so I would like to > reorganise and update the documentation. Plus I want to make it w3c > compatible, since it does not work in Opera and is a little outdated. > If anybody has any input on that, please let me know. This would be great. > - Better access and overview of all resources included in a project: src > files, test src, build scripts, config files, libraries etc. The ECB is the way forward here. > - Essentially I want something like what eclipse has, the directory > tree on the left side, which lists everything included in the project. > It gives easy access to any resource in the project, independent of > which directory its in and how complicated the name is. > - Another solution could be something that search the entire > project or something. There are quite a few systems for doing this depending on exactly how you want to search. I use find-dired and grep-find a lot for basic searching. > - Better movement between buffers and resouces > - In eclipse there are window panes, that allows you to easily find > one of your many current windows. > - In jdee there is only buffers and they have to be selected by > typing the name of the buffer, every time you want to switch. it does > not have a good history function so it takes up to 20 seconds to switch > to another buffer than the previous one. ido.el makes both buffer and file switching very, very fast. > - Better code completion, one that is faster, more accurate and, last > but not least, more user-friendly. It should also support completing > all included libraries etc. JDEE does library aware completion. I use pabbrev.el (which I am fond of, partly because I wrote it), which is dumb, works on text analysis, but seems to work well. There are other options here. > - Better compile cycle support, the > whole code - compile - fix-bug - run > cycle. It is probably there but I havent figured out how to set it up. JDEE is rather tied to an underlying build tool. It can drive maven or ant pretty well, and will the right thing with the output. > The more advanced stuff is: > > - refactoring support, > - mainly renaming and moving methods, attributes, This it doesn't have. > - code wizards > - which help automate creating classes for specific purposes in the > program. I know there is some support for it, but I feel its not > complete. Probably true; there could be more here. > - what I specifically want is a function that does all the mundane > operations related to creating, or including, a class, adding it > to the project, storing it in the right directory/package etc. etc. JDEE works the other way around; you put it into the right directory, then it works out the package for you. > - additionally help create other mundane methods or classes one needs, > e.g. enum classes, parameter classes etc. True. > - javadoc access that works in all browsers javadoc access comes from browse-url -- again this should work. > finally I want all of this packaged into an install file that sets > eveything up for me, easily, without a lot of reading and manual > configuring. Yes, this could help a lot. It's one area that Emacs as a whole is still lacking. It's very powerful, but it can take a while to learn. Phil |
From: Paul K. <Pau...@ma...> - 2008-11-24 20:11:23
|
Hi Thomas, The JDEE was developed for users who are familiar and comfortable with the Emacs environment. The JDEE attempts to provide as many of the features of a GUI development environment as can comfortable fit within the Emacs framework, which reached maturity in and hence largely reflects the mindset and limitations of a preGUI age. It is not feasible at this point to substantially alter the framework itself. Using the JDEE productively requires acceptance of and mastery of the basic Emacs framework and thus entails a substantial learning curve for someone who is new to Emacs itself. Learning the Emacs way can be especially puzzling and aggravating to anyone who has grown up with modern GUI editors and IDEs and therefore cannot easily envision the problems that dictated its design. For this reason, the JDEE is probably not the best IDE choice for someone from a modern GUI background. Paul > -----Original Message----- > From: Thomas Finneid [mailto:tfi...@fc...] > Sent: Monday, November 24, 2008 2:26 PM > To: jde...@li... > Subject: Re: [jdee-devel] functionality development > > Phillip Lord wrote: > > > > You're trying to do too much with JDEE and not enough with Emacs. A > lot > > of this is very general and not specific to java. It's provide by > other > > packages. > > Perhaps, I shall look for the functionality elsewhere. Can you suggest > some place I can find it? > > But there is a problem how some of it works and some of the > functionality I want, is specific to java. > > My biggest problem with the emacs philosophy is that it is too > difficult > to figure out what functionality exists, where to find it and how it > works. > > thomas > > > > > > > Thomas Finneid <tfi...@fc...> writes: > >> First of all I want better documentation of jdee, so I would like to > >> reorganise and update the documentation. Plus I want to make it w3c > >> compatible, since it does not work in Opera and is a little outdated. > >> If anybody has any input on that, please let me know. > > > > This would be great. > > > > > >> - Better access and overview of all resources included in a project: > src > >> files, test src, build scripts, config files, libraries etc. The > > > > ECB is the way forward here. > > > >> - Essentially I want something like what eclipse has, the > directory > >> tree on the left side, which lists everything included in the > project. > >> It gives easy access to any resource in the project, > independent of > >> which directory its in and how complicated the name is. > >> - Another solution could be something that search the entire > >> project or something. > > > > There are quite a few systems for doing this depending on exactly how > > you want to search. I use find-dired and grep-find a lot for basic > > searching. > > > >> - Better movement between buffers and resouces > >> - In eclipse there are window panes, that allows you to easily > find > >> one of your many current windows. > >> - In jdee there is only buffers and they have to be selected by > >> typing the name of the buffer, every time you want to switch. it > does > >> not have a good history function so it takes up to 20 seconds to > switch > >> to another buffer than the previous one. > > > > ido.el makes both buffer and file switching very, very fast. > > > >> - Better code completion, one that is faster, more accurate and, > last > >> but not least, more user-friendly. It should also support > completing > >> all included libraries etc. > > > > JDEE does library aware completion. I use pabbrev.el (which I am fond > > of, partly because I wrote it), which is dumb, works on text analysis, > > but seems to work well. There are other options here. > > > > > >> - Better compile cycle support, the > >> whole code - compile - fix-bug - run > >> cycle. It is probably there but I havent figured out how to set > it up. > > > > JDEE is rather tied to an underlying build tool. It can drive maven > or > > ant pretty well, and will the right thing with the output. > > > > > >> The more advanced stuff is: > >> > >> - refactoring support, > >> - mainly renaming and moving methods, attributes, > > > > > > This it doesn't have. > > > > > >> - code wizards > >> - which help automate creating classes for specific purposes in > the > >> program. I know there is some support for it, but I feel its > not > >> complete. > > > > > > Probably true; there could be more here. > > > >> - what I specifically want is a function that does all the > mundane > >> operations related to creating, or including, a class, adding > it > >> to the project, storing it in the right directory/package etc. > etc. > > > > > > JDEE works the other way around; you put it into the right directory, > > then it works out the package for you. > > > > > >> - additionally help create other mundane methods or classes one > needs, > >> e.g. enum classes, parameter classes etc. > > > > True. > > > >> - javadoc access that works in all browsers > > > > javadoc access comes from browse-url -- again this should work. > > > > > >> finally I want all of this packaged into an install file that sets > >> eveything up for me, easily, without a lot of reading and manual > >> configuring. > > > > Yes, this could help a lot. It's one area that Emacs as a whole is > still > > lacking. It's very powerful, but it can take a while to learn. > > > > Phil > > > > --------------------------------------------------------------------- > ---- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win > great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > jdee-devel mailing list > > jde...@li... > > https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Paul K. <Pau...@ma...> - 2008-11-21 15:03:24
|
My email wasn't referring to commands, it was referring to completion of object method and field names, e.g., myobj.getN -> myobj.getName(). Anyway, why are you interested in tags? Tags is an outdated code completion technology developed for functional languages, such as C, that cannot complete with class introspection-based technologies, such as that used in the JDEE. With class introspection-based techniques, there is no need to generate and maintain a completion database. The classpath is the completion database. Further, introspection-based techniques offer only the range of completion choices appropriate for the class of the object at point in contrast to tags-based completion, which offers completion choices for every candidate in the tags database, regardless of whether it is appropriate to the object at point. Paul > -----Original Message----- > From: Thomas Finneid [mailto:tfi...@fc...] > Sent: Friday, November 21, 2008 3:37 AM > To: jde...@li... > Subject: Re: [jdee-devel] functionality development > > Hi > > I know, but I was not asking about command completion though. I was > asking about tags etc. which requires code parsing, in similar fashion > to command completion. Eric mentioned BeanShell, I dont know much about > it but maybe I misunderstood. > > regards > > thomas > > Paul Kinnucan wrote: > > Eric is correct. The JDEE has had an intelligent, Java-aware > completion facility for a long time, i.e., it is based on identifying > the class of the object whose field or method you are attempting to > complete, using Java inspection to find all the methods and fields > defined or inherited by that class, and then providing you with the > subset of those method and field names that complete the expression at > point. See the documentation. > > > > Paul > > > >> -----Original Message----- > >> From: Eric M. Ludlam [mailto:er...@si...] > >> Sent: Thursday, November 20, 2008 2:06 PM > >> To: Phillip Lord > >> Cc: jde...@li... > >> Subject: Re: [jdee-devel] functionality development > >> > >>>>> Phillip Lord <phi...@ne...> seems to think that: > >>> > >>> Thomas Finneid <tfi...@fc...> writes: > >> [ ... ] > >>>> I have been using the standard ctags/etags program and the > standard > >>>> emacs tags functionality. But for java development it seems to > lack > >> some > >>>> features which make it more efficient. > >>>> > >>>> For example, a tag search does not seem to take context of a > method > >> call > >>>> into consideration. This means all possible getX() methods in the > >> source > >>>> code is visited, one after another. What it should do is: if the > >> method > >>>> call is prefixed with an instance reference or class name, it > should > >>>> start the search in that class and expand outwards as appropriate. > >> It > >>>> shold not f.ex. start in the class that is alphabetically first in > >> the > >>>> tags list. Other things i feel is missing is that searches should > >>>> differentiate between interfaces and classes, one implementation > of > >> an > >>>> interface from another (in f.ex. a separate package) and so on > >>>> > >>>> If there is no tags program or emacs functionality to support this > I > >>>> would like to help by developing this, I just need to know what is > >> the > >>>> preferred approach to extend functionality. > >>>> > >> [ ... ] > >>> Sorry that this part of my answer is pretty useless; I tend to just > >>> grep when I need this functionality. > >> [ ... ] > >> > >> Semantic can find a tag based on code context accurately based on > the > >> object type in the code, not just on the name. For C++, it gets it > >> right all the time. At least, in the code I've run it on. > >> > >> As I don't code in Java, I've not tested it there. If it doesn't > >> work, the tweak needed would be very small. I've not worried much > >> about the Java piece because I assumed the beanshell feature solved > >> this issue already. > >> > >> Eric > >> > >> -- > >> Eric Ludlam: er...@si... > >> Siege: www.siege-engine.com Emacs: > >> http://cedet.sourceforge.net > >> > >> -------------------------------------------------------------------- > --- > >> -- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win > great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in > the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> jdee-devel mailing list > >> jde...@li... > >> https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > > --------------------------------------------------------------------- > ---- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win > great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > jdee-devel mailing list > > jde...@li... > > https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Yee K. P. <yk...@gm...> - 2008-11-22 08:16:51
|
Hi, On Fri, Nov 21, 2008 at 11:03 PM, Paul Kinnucan <Pau...@ma...> wrote: > Anyway, why are you interested in tags? Although I haven't get into any type of research or testing, I thought tags will be a lot faster compared to any type of introspection method. I am not sure, completion in jdee (even with jde-usages) just seems very slow, if compared to code completion in eclipse. Cheers, Phuah Yee Keat |
From: Thomas F. <tfi...@fc...> - 2008-11-22 08:28:27
|
Paul Kinnucan wrote: > My email wasn't referring to commands, it was referring to completion of object method and field names, e.g., > > myobj.getN -> myobj.getName(). Its the same principle, just used in different contexts, one in a bash another in an ide. I am asking because I want refactoring support in jdee, for that to work the tool must first be able to parse the code so that it can know what code to move and where to move it. My impression was that there is little support or tools for refatcoring for jdee, so I was wondering about writing such a tool myself. > > Anyway, why are you interested in tags? Tags is an outdated code completion technology developed for functional languages, such as C, that cannot complete with class introspection-based technologies, such as that used in the JDEE. With class introspection-based techniques, there is no need to generate and maintain a completion database. The classpath is the completion database. Further, introspection-based techniques offer only the range of completion choices appropriate for the class of the object at point in contrast to tags-based completion, which offers completion choices for every candidate in the tags database, regardless of whether it is appropriate to the object at point. That all depends on how its is done. Classical ctags/etags work like you describe, but there is no reason it can nott support other ways of doing it. I dont know if there are other tags programs that have better support for java than the classical ones. There is Exuberant Tags, but I dont know enough about it. In any case, no matter how its done is has to be working properly and be fast. The code completion functionality I have seen in jdee does not work very well. Its slow and not very user-friendly. But if you have any information on how to make it work better then please share. regards thomas |
From: Thomas F. <tfi...@fc...> - 2008-11-24 19:26:08
|
Phillip Lord wrote: > > You're trying to do too much with JDEE and not enough with Emacs. A lot > of this is very general and not specific to java. It's provide by other > packages. Perhaps, I shall look for the functionality elsewhere. Can you suggest some place I can find it? But there is a problem how some of it works and some of the functionality I want, is specific to java. My biggest problem with the emacs philosophy is that it is too difficult to figure out what functionality exists, where to find it and how it works. thomas > > > Thomas Finneid <tfi...@fc...> writes: >> First of all I want better documentation of jdee, so I would like to >> reorganise and update the documentation. Plus I want to make it w3c >> compatible, since it does not work in Opera and is a little outdated. >> If anybody has any input on that, please let me know. > > This would be great. > > >> - Better access and overview of all resources included in a project: src >> files, test src, build scripts, config files, libraries etc. The > > ECB is the way forward here. > >> - Essentially I want something like what eclipse has, the directory >> tree on the left side, which lists everything included in the project. >> It gives easy access to any resource in the project, independent of >> which directory its in and how complicated the name is. >> - Another solution could be something that search the entire >> project or something. > > There are quite a few systems for doing this depending on exactly how > you want to search. I use find-dired and grep-find a lot for basic > searching. > >> - Better movement between buffers and resouces >> - In eclipse there are window panes, that allows you to easily find >> one of your many current windows. >> - In jdee there is only buffers and they have to be selected by >> typing the name of the buffer, every time you want to switch. it does >> not have a good history function so it takes up to 20 seconds to switch >> to another buffer than the previous one. > > ido.el makes both buffer and file switching very, very fast. > >> - Better code completion, one that is faster, more accurate and, last >> but not least, more user-friendly. It should also support completing >> all included libraries etc. > > JDEE does library aware completion. I use pabbrev.el (which I am fond > of, partly because I wrote it), which is dumb, works on text analysis, > but seems to work well. There are other options here. > > >> - Better compile cycle support, the >> whole code - compile - fix-bug - run >> cycle. It is probably there but I havent figured out how to set it up. > > JDEE is rather tied to an underlying build tool. It can drive maven or > ant pretty well, and will the right thing with the output. > > >> The more advanced stuff is: >> >> - refactoring support, >> - mainly renaming and moving methods, attributes, > > > This it doesn't have. > > >> - code wizards >> - which help automate creating classes for specific purposes in the >> program. I know there is some support for it, but I feel its not >> complete. > > > Probably true; there could be more here. > >> - what I specifically want is a function that does all the mundane >> operations related to creating, or including, a class, adding it >> to the project, storing it in the right directory/package etc. etc. > > > JDEE works the other way around; you put it into the right directory, > then it works out the package for you. > > >> - additionally help create other mundane methods or classes one needs, >> e.g. enum classes, parameter classes etc. > > True. > >> - javadoc access that works in all browsers > > javadoc access comes from browse-url -- again this should work. > > >> finally I want all of this packaged into an install file that sets >> eveything up for me, easily, without a lot of reading and manual >> configuring. > > Yes, this could help a lot. It's one area that Emacs as a whole is still > lacking. It's very powerful, but it can take a while to learn. > > Phil > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Paul L. <la...@ma...> - 2008-11-25 06:57:27
|
Thomas Finneid writes: > Phillip Lord wrote: > > > > You're trying to do too much with JDEE and not enough with Emacs. A lot > > of this is very general and not specific to java. It's provide by other > > packages. > > Perhaps, I shall look for the functionality elsewhere. Can you suggest > some place I can find it? The IDEs I've seen around are: - (My)Eclipse - IntelliJ - NetBeans - JEdit (this one is interesting) > But there is a problem how some of it works and some of the > functionality I want, is specific to java. Have you thought of Eclipse plug-ins? > My biggest problem with the emacs philosophy is that it is too difficult > to figure out what functionality exists, where to find it and how it works. The Emacs learning curve is painful. Emacs + Lisp is even worse. However, the effort is rewarding. I hated lisp when I started with it, however, now I prefer it to other languages. You might want to start with the function apropos: M-x apropos-command ^jde-gen RET to learn about all the JDE code generation commands, which are interactive functions. > thomas > > > > > > > Thomas Finneid <tfi...@fc...> writes: > >> First of all I want better documentation of jdee, so I would like to > >> reorganise and update the documentation. Plus I want to make it w3c > >> compatible, since it does not work in Opera and is a little outdated. > >> If anybody has any input on that, please let me know. > > > > This would be great. > > > > > >> - Better access and overview of all resources included in a project: src > >> files, test src, build scripts, config files, libraries etc. The > > > > ECB is the way forward here. > > > >> - Essentially I want something like what eclipse has, the directory > >> tree on the left side, which lists everything included in the project. > >> It gives easy access to any resource in the project, independent of > >> which directory its in and how complicated the name is. > >> - Another solution could be something that search the entire > >> project or something. > > > > There are quite a few systems for doing this depending on exactly how > > you want to search. I use find-dired and grep-find a lot for basic > > searching. > > > >> - Better movement between buffers and resouces > >> - In eclipse there are window panes, that allows you to easily find > >> one of your many current windows. > >> - In jdee there is only buffers and they have to be selected by > >> typing the name of the buffer, every time you want to switch. it does > >> not have a good history function so it takes up to 20 seconds to switch > >> to another buffer than the previous one. > > > > ido.el makes both buffer and file switching very, very fast. > > > >> - Better code completion, one that is faster, more accurate and, last > >> but not least, more user-friendly. It should also support completing > >> all included libraries etc. > > > > JDEE does library aware completion. I use pabbrev.el (which I am fond > > of, partly because I wrote it), which is dumb, works on text analysis, > > but seems to work well. There are other options here. > > > > > >> - Better compile cycle support, the > >> whole code - compile - fix-bug - run > >> cycle. It is probably there but I havent figured out how to set it up. > > > > JDEE is rather tied to an underlying build tool. It can drive maven or > > ant pretty well, and will the right thing with the output. > > > > > >> The more advanced stuff is: > >> > >> - refactoring support, > >> - mainly renaming and moving methods, attributes, > > > > > > This it doesn't have. > > > > > >> - code wizards > >> - which help automate creating classes for specific purposes in the > >> program. I know there is some support for it, but I feel its not > >> complete. > > > > > > Probably true; there could be more here. > > > >> - what I specifically want is a function that does all the mundane > >> operations related to creating, or including, a class, adding it > >> to the project, storing it in the right directory/package etc. etc. > > > > > > JDEE works the other way around; you put it into the right directory, > > then it works out the package for you. > > > > > >> - additionally help create other mundane methods or classes one needs, > >> e.g. enum classes, parameter classes etc. > > > > True. > > > >> - javadoc access that works in all browsers > > > > javadoc access comes from browse-url -- again this should work. > > > > > >> finally I want all of this packaged into an install file that sets > >> eveything up for me, easily, without a lot of reading and manual > >> configuring. > > > > Yes, this could help a lot. It's one area that Emacs as a whole is still > > lacking. It's very powerful, but it can take a while to learn. > > > > Phil > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > jdee-devel mailing list > > jde...@li... > > https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel -- Paul Landes la...@ma... |
From: Thomas F. <tfi...@fc...> - 2008-11-25 08:21:23
|
Paul Landes wrote: > Thomas Finneid writes: > > Phillip Lord wrote: > > > > > > You're trying to do too much with JDEE and not enough with Emacs. A lot > > > of this is very general and not specific to java. It's provide by other > > > packages. > > > > Perhaps, I shall look for the functionality elsewhere. Can you suggest > > some place I can find it? > > The IDEs I've seen around are: Sorry, I meant in other emacs packages, not in other IDEs. As you pointed out, much of the functionality comes from other packages, not from jde. So, evidently, I need to understand everything well enough before there is a need for me to start coding new functionality As, already stated I will have a look at the jde documentation again and see if I can set it up correctly this time. thomas |
From: Phillip L. <phi...@ne...> - 2008-11-25 13:28:57
|
Thomas Finneid <tfi...@fc...> writes: > Phillip Lord wrote: >> >> You're trying to do too much with JDEE and not enough with Emacs. A lot >> of this is very general and not specific to java. It's provide by other >> packages. > > Perhaps, I shall look for the functionality elsewhere. Can you suggest > some place I can find it? I said where in my first reply. ECB, ido, browse-url and a build tool. > > But there is a problem how some of it works and some of the > functionality I want, is specific to java. > > My biggest problem with the emacs philosophy is that it is too difficult > to figure out what functionality exists, where to find it and how it works. I agree that it can be an unhill struggle at times. A package manager for Emacs would be a great thing -- funnily enough, java has the same problem. Again, people are aware of these issues; The Emacs wiki was an attempt to help with the problem, for example. It's a 20 year old tool; that has big advantages but causes problems as well. Phil |
From: Thomas F. <tfi...@fc...> - 2008-11-24 22:34:12
|
You misunderstand what I am saying. I have been using emacs on linux for 13 years, so I know all this, but I still find certain aspects of it confusing. My point is that because the emacs environment has a steep learning curve, there are certain things that can be done to alleviate that. And one of the most important aspects of that is good documentation. Which has always been a problem with the emacs environment. I would like to contribute on the web page and documentation part first, so that I can get to understand jde properly and then I would like to contribute on java related functionality, so that I can have a more complete environment. Yes some functionality does come from other packages, but some of those functionalities seem to be incomplete or not as efficient as could be. So I am hoping you guys will help me identify what to look for and where, so I can stitch together an java devel environment that works well. If that requires contributing some code, I will. thomas Paul Kinnucan wrote: > Hi Thomas, > > The JDEE was developed for users who are familiar and comfortable with the Emacs environment. The JDEE attempts to provide as many of the features of a GUI development environment as can comfortable fit within the Emacs framework, which reached maturity in and hence largely reflects the mindset and limitations of a preGUI age. It is not feasible at this point to substantially alter the framework itself. Using the JDEE productively requires acceptance of and mastery of the basic Emacs framework and thus entails a substantial learning curve for someone who is new to Emacs itself. Learning the Emacs way can be especially puzzling and aggravating to anyone who has grown up with modern GUI editors and IDEs and therefore cannot easily envision the problems that dictated its design. For this reason, the JDEE is probably not the best IDE choice for someone from a modern GUI background. > > Paul > >> -----Original Message----- >> From: Thomas Finneid [mailto:tfi...@fc...] >> Sent: Monday, November 24, 2008 2:26 PM >> To: jde...@li... >> Subject: Re: [jdee-devel] functionality development >> >> Phillip Lord wrote: >>> You're trying to do too much with JDEE and not enough with Emacs. A >> lot >>> of this is very general and not specific to java. It's provide by >> other >>> packages. >> Perhaps, I shall look for the functionality elsewhere. Can you suggest >> some place I can find it? >> >> But there is a problem how some of it works and some of the >> functionality I want, is specific to java. >> >> My biggest problem with the emacs philosophy is that it is too >> difficult >> to figure out what functionality exists, where to find it and how it >> works. >> >> thomas >> >>> >>> Thomas Finneid <tfi...@fc...> writes: >>>> First of all I want better documentation of jdee, so I would like to >>>> reorganise and update the documentation. Plus I want to make it w3c >>>> compatible, since it does not work in Opera and is a little outdated. >>>> If anybody has any input on that, please let me know. >>> This would be great. >>> >>> >>>> - Better access and overview of all resources included in a project: >> src >>>> files, test src, build scripts, config files, libraries etc. The >>> ECB is the way forward here. >>> >>>> - Essentially I want something like what eclipse has, the >> directory >>>> tree on the left side, which lists everything included in the >> project. >>>> It gives easy access to any resource in the project, >> independent of >>>> which directory its in and how complicated the name is. >>>> - Another solution could be something that search the entire >>>> project or something. >>> There are quite a few systems for doing this depending on exactly how >>> you want to search. I use find-dired and grep-find a lot for basic >>> searching. >>> >>>> - Better movement between buffers and resouces >>>> - In eclipse there are window panes, that allows you to easily >> find >>>> one of your many current windows. >>>> - In jdee there is only buffers and they have to be selected by >>>> typing the name of the buffer, every time you want to switch. it >> does >>>> not have a good history function so it takes up to 20 seconds to >> switch >>>> to another buffer than the previous one. >>> ido.el makes both buffer and file switching very, very fast. >>> >>>> - Better code completion, one that is faster, more accurate and, >> last >>>> but not least, more user-friendly. It should also support >> completing >>>> all included libraries etc. >>> JDEE does library aware completion. I use pabbrev.el (which I am fond >>> of, partly because I wrote it), which is dumb, works on text analysis, >>> but seems to work well. There are other options here. >>> >>> >>>> - Better compile cycle support, the >>>> whole code - compile - fix-bug - run >>>> cycle. It is probably there but I havent figured out how to set >> it up. >>> JDEE is rather tied to an underlying build tool. It can drive maven >> or >>> ant pretty well, and will the right thing with the output. >>> >>> >>>> The more advanced stuff is: >>>> >>>> - refactoring support, >>>> - mainly renaming and moving methods, attributes, >>> >>> This it doesn't have. >>> >>> >>>> - code wizards >>>> - which help automate creating classes for specific purposes in >> the >>>> program. I know there is some support for it, but I feel its >> not >>>> complete. >>> >>> Probably true; there could be more here. >>> >>>> - what I specifically want is a function that does all the >> mundane >>>> operations related to creating, or including, a class, adding >> it >>>> to the project, storing it in the right directory/package etc. >> etc. >>> >>> JDEE works the other way around; you put it into the right directory, >>> then it works out the package for you. >>> >>> >>>> - additionally help create other mundane methods or classes one >> needs, >>>> e.g. enum classes, parameter classes etc. >>> True. >>> >>>> - javadoc access that works in all browsers >>> javadoc access comes from browse-url -- again this should work. >>> >>> >>>> finally I want all of this packaged into an install file that sets >>>> eveything up for me, easily, without a lot of reading and manual >>>> configuring. >>> Yes, this could help a lot. It's one area that Emacs as a whole is >> still >>> lacking. It's very powerful, but it can take a while to learn. >>> >>> Phil >>> >>> --------------------------------------------------------------------- >> ---- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >>> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> jdee-devel mailing list >>> jde...@li... >>> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> >> ----------------------------------------------------------------------- >> -- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Phillip L. <phi...@ne...> - 2008-11-25 13:33:52
|
Thomas Finneid <tfi...@fc...> writes: > I would like to contribute on the web page and documentation part first, > so that I can get to understand jde properly and then I would like to > contribute on java related functionality, so that I can have a more > complete environment. Yes some functionality does come from other > packages, but some of those functionalities seem to be incomplete or not > as efficient as could be. That seems like a very positive idea. A "how-to" document which points people at those parts of JDEE where it provides functionality and other packages where it does not. The documentation does some of this already, but more would be better. ECB is perhaps the most obvious example of a closely related tool. An nicely put together, integrated download with configuration of JDEE and ECB would be a great thing also. Phil |
From: Espen W. <es...@gr...> - 2008-11-25 08:27:36
|
Phillip Lord <phi...@ne...> writes: > Thomas Finneid <tfi...@fc...> writes: >> - Essentially I want something like what eclipse has, the >> directory tree on the left side, which lists everything included in >> the project. It gives easy access to any resource in the project, >> independent of which directory its in and how complicated the name >> is. - Another solution could be something that search the entire >> project or something. > There are quite a few systems for doing this depending on exactly how > you want to search. I use find-dired and grep-find a lot for basic > searching. And do not underestimate the power of jde-open-class-at-point, especially if you use (shameless plug time) Maven with jde-mvn and tell it to add any source artifacts it finds to the source path. >> - Better code completion, one that is faster, more accurate and, last >> but not least, more user-friendly. It should also support completing >> all included libraries etc. > JDEE does library aware completion. I use pabbrev.el (which I am fond > of, partly because I wrote it), which is dumb, works on text analysis, > but seems to work well. There are other options here. I mostly use dabbrev-expand, myself. Intellisense-style completion is most useful when exploring an unfamiliar API, but in those cases I usually find myself leaning on the javadocs anyway. >> The more advanced stuff is: >> >> - refactoring support, >> - mainly renaming and moving methods, attributes, > This it doesn't have. Synchronicity strikes again! I've just started an effort in this direction; see http://www.bitbucket.org/espenhw/jde-refactor/ for status, news and views. -- Espen Wiborg <es...@gr...> - Veritas vos liberabit Away each minus wordlessly that, possessing heavier minus better. |
From: Thomas F. <tfi...@fc...> - 2008-11-25 09:35:21
|
Espen Wiborg wrote: >>> The more advanced stuff is: >>> >>> - refactoring support, >>> - mainly renaming and moving methods, attributes, >> This it doesn't have. > > Synchronicity strikes again! I've just started an effort in this > direction; see http://www.bitbucket.org/espenhw/jde-refactor/ for > status, news and views. Briliant, maybe Ill join you. I looked at xrefactory, but it does not support java 1.5 and upwards. Ill just have to et a complete understanding of what I want and what emacs/jde supports first. thomas |
From: Phillip L. <phi...@ne...> - 2008-11-25 13:35:57
|
Espen Wiborg <es...@gr...> writes: > I mostly use dabbrev-expand, myself. Intellisense-style completion is > most useful when exploring an unfamiliar API, but in those cases I > usually find myself leaning on the javadocs anyway. Do give pabbrev.el a go at some point if you haven't. It's far better in every way than dabbrev.el; trust me on this, I am totally and utterly unbiased in every way. Phil |