Re: [ jEdit-users ] java dev platform

[Dale A. <da...@gr...>]

One thing that I have seen people at work use in Eclipse is the API 
documentation popups.  I don't recall what triggers that off hand 
(hovering the mouse over a word?  Double clicking on something?), 
regardless, I've thought for a while that JavaSideKick has a lot of the 
pieces in place to provide this feature.  I'll take a look at adding it.

I've also got a feeling that JavaSideKick has the info necessary to 
implement the 'hyperlink' feature, I'll take a look at the possibility of 
that.

Dale



On Mon, 29 May 2006, Andy Streich wrote:

> On Monday 29 May 2006 02:23 pm, Dale Anson wrote:
>> About integrated debuggers -- I've been doing Java work since the first
>> beta version of Java, back in 1995 (? 1996 maybe?) anyway, about 10 years.
>> I've never found the need for a debugger.  I quit using debuggers when I
>> quit doing C and C++ work. Seriously, I've never found anything that I
>> couldn't debug with either simple System.out.println's or perhaps a logger
>> of some sort.  I really don't see the value of having an integrated
>> debugger for Java development, but, of course, that's just my opinion.
>
> Certainly there are nearly as many ways of working as there are people who
> write code.  For me, with respect to a debugger being needed in a tool that
> wants to be called an IDE, it is all about productivity and learning.  Yes,
> given enough time most anything can be debugged with println().  With a
> debugger, though, (and modern ones are fabulous) you can see call stacks,
> stack frames, and active threads without modifying your code -- which means
> developers have less excuse for not understanding what's going on and can
> find out faster.  It can also be useful for things you might not normally
> think of like checking correctness of, or clarifying, API documentation.
>
>> Another thing I didn't see mentioned is SCM integration.  jEdit has
>> plugins for CVS and Perforce, and I have a set of macros that I use, but
>> to me, this is one of the few things that I switch away from jEdit to use.
>
> This is a bit of a theme on this thread:  jEdit has plugins for X or macros
> can be written to do X, but we switch to other tools -- I assume because they
> do X more efficiently or a plugin maintainer when on to other things or why
> bother to write the macro or plugin if you already have an effective
> solution.
>
>> I recall some time ago there was talk on this list about creating
>> different "distributions" of jEdit, like jEdit with a bundle of plugins
>> for Java development that would include a good set of java plugins, one
>> for web development that would have html, php, and javascript support, and
>> so on.
>
> I was one of the people rather high on the idea.  It's like meta-packages in
> the Debian GNU/Linux distro.  The meta package simply creates a dependency on
> other packages.  Seems rather simple to implement too since some dependency
> checking is already in place.
>
> Currently, to deliver a particular configuration of jEdit to someone, you are
> completely on your own.  If they have used jEdit before or if you want to
> deliver a subset of what you are using,  it's not as simple as  just zipping
> the files under ${user.home}.jEdit.
>
> A related idea is creating a smooth way to associate things like new mode and
> commando files with a plugin install, perhaps in the manner similar to what
> is done for macro's now.
>
> Cheers,
>
> Andy
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Users' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-users
>