Re: [jdee-devel] functionality development
Brought to you by:
paullandes
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 |