Jde-help and wget

[Nascif Abousalh-Neto]

Hi,

I was trying to configure jde-help to see some javadoc directories in Jakarta 
(the commons libraries) and I had to fix a number of problems in the process. 
Here is what I did in the hopes it might help someone else:

1) Once I enabled the extra docsets pointing to the jakarta javadocs, 
jde-help-symbol started to fail with a very cryptic message, something like 
"wrong type, (sequencep, 2)" or something like that . I traced it down to the 
method jde-help-find-javadoc, more precisely to this code:

 (if jde-help-wget-tries
 (concat "--tries=" jde-help-wget-tries))

I fixed by changing it to:

 (if jde-help-wget-tries
 (concat "--tries="  (format "%d" 
jde-help-wget-tries)))

Same thing on the line below:
 (if jde-help-wget-timeout
 (concat "--timeout="  (format "%d" 
jde-help-wget-timeout)))

2) After that step wget was still failing on me - but then it was a local 
environment problem, since we use an http proxy at work. Adding a .wgetrc with 
the proper info solved the problem.

It seems that jde-help tries all the docsets, even if it finds the help for the 
class at point in the first one. I believe this should be optimized - it is 
already a little slow as is.

Regards,
  Nascif

Jde-import-kill-extra-imports problem

[Nascif Abousalh-Neto]

Really minor thing, but it does not skip over commented code, so it might think 
you still need classes that are not really necessary anymore.
Thanks,
  Nascif

RE: Re[4]: "header line" bugs and artifacts

[Nascif Abousalh-Neto]

Hi again,

I think those improvements will be nice. As for your question, I would guess 
that in 90% of the times what scares people away (and creates the urge to turn 
things off) are the semantic decorations, that 1) are visually very intrusive 
and 2) come as a complete surprise. I think a lot of users are getting CEDET 
because it is a requirememnt for JDE and/or ECB - so they may have not read its 
documentation, assuming it is just a "under-the-covers" library like a parser 
(which it is) not realizing it has also UI-affecting features. Underlines are 
also bad because they hide underscores (a small problem that can be annoying 
sometimes).

Perhaps using the fringe now that Emacs allows you to have more control on what 
goes there? I think other IDEs (e.g. Eclipse) take that approach, of adding 
small icons on a left to give you feedback about the code. Just an idea :-)

Regards,
  Nascif

> -Original Message-
> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 28, 2005 8:08 AM
> To: Nascif Abousalh-Neto
> Cc: [EMAIL PROTECTED]; jde@sunsite.dk
> Subject: Re[4]: "header line" bugs and artifacts
> 
> Hi,
> 
>   Thanks for the input.  All I usually see is "What is that 
> and how to I turn it off?", and after an explanation, "oh, 
> that's neat."  As such, I don't get this perspective.
> 
>   I've been fiddling with the header line already.  In the 
> next version, clicking on it will provide a menu with a few 
> semantic things in it, and a "what is this?" note in it.
> 
>   The decorations should probably have an explicit list in a 
> menu to be turned on and off.
> 
>   In the meantime, I will split the default "code-helpers" 
> install into two sections.  The basic code helpers will have 
> the subtle stuff, and then move stickyfunc and decoration 
> mode into the existing excessive setup fcn.
> 
>   I'll also update the semantic INSTALL file to make it 
> easier to do a custom setup.
> 
>   To be clear, is it just the header line, and semantic 
> decorations that scare people away, or the whole set of code 
> helpers including imenu, summary-mode, completion mode, and what-not.
> 
> Thanks
> Eric
> 
> >>> "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> 
> seems to think that:
> >Hi Eric,
> >
> >This approach can also be overwhelming and frustrating - I 
> saw it first 
> >hand with some co-workers, having to stop their work to find out and 
> >turn off new features they didn't want in the first place.
> >
> >Another tactic might be to start with the more powerful features 
> >disabled and provide documentation on them, including screenshots. 
> >Curious users will find the info and tinker with them, and 
> spread the 
> >word in wikis and mailing lists; less sophisticated users won't be 
> >frustrated with all the colors and extra fontification 
> getting in their 
> >way, coming from nowhere, as soon as they install the new 
> library. They 
> >might them be more receptive to turn them on later.
> >
> >Best regards,
> >  Nascif
> >
> >
> >> -Original Message-
> >> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]
> >> Sent: Saturday, April 23, 2005 8:46 AM
> >> To: Felix Dorner
> >> Cc: jde@sunsite.dk
> >> Subject: Re[2]: "header line" bugs and artifacts
> >> 
> >> Hi,
> >> 
> >>   Stickyfunc mode puts the first line of the method/class 
> that is on 
> >> the top line of the window into the header line.
> >> That way you can always see what function you are working on. 
> >>  It's something I always thought would be useful.
> >> 
> >>   The overline is simply a decoration to help divide 
> different types 
> >> of tags from eachother in the buffer.  I copied the idea from some 
> >> Java editor I saw a coworker using.
> >>  It is a part of semantic-decoration-mode.  You can 
> concoct your own 
> >> decorations with `define-semantic-decoration-style'.
> >> 
> >>   I have seen several times that people look at these 
> things and go 
> >> "Eeww!  What's all this?"  and after a little bit change 
> their minds 
> >> and think they are useful.
> >> 
> >>   You can turn all the "code-helpers" off and suffer no 
> ill effect.  
> >> I turn most things on in the default so you get exposed to 
> them, and 
> >> can later choose which tools you like and turn off the others.
> >> 
> >> Eric
> >> 
> &g

RE: Re[2]: "header line" bugs and artifacts

[Nascif Abousalh-Neto]

Hi Eric,

This approach can also be overwhelming and frustrating - I saw it first hand 
with some co-workers, having to stop their work to find out and turn off new 
features they didn't want in the first place. 

Another tactic might be to start with the more powerful features disabled and 
provide documentation on them, including screenshots. Curious users will find 
the info and tinker with them, and spread the word in wikis and mailing lists; 
less sophisticated users won't be frustrated with all the colors and extra 
fontification getting in their way, coming from nowhere, as soon as they 
install the new library. They might them be more receptive to turn them on 
later.

Best regards,
  Nascif


> -Original Message-
> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, April 23, 2005 8:46 AM
> To: Felix Dorner
> Cc: jde@sunsite.dk
> Subject: Re[2]: "header line" bugs and artifacts
> 
> Hi,
> 
>   Stickyfunc mode puts the first line of the method/class 
> that is on the top line of the window into the header line.  
> That way you can always see what function you are working on. 
>  It's something I always thought would be useful.
> 
>   The overline is simply a decoration to help divide 
> different types of tags from eachother in the buffer.  I 
> copied the idea from some Java editor I saw a coworker using. 
>  It is a part of semantic-decoration-mode.  You can concoct 
> your own decorations with `define-semantic-decoration-style'.
> 
>   I have seen several times that people look at these things 
> and go "Eeww!  What's all this?"  and after a little bit 
> change their minds and think they are useful.
> 
>   You can turn all the "code-helpers" off and suffer no ill 
> effect.  I turn most things on in the default so you get 
> exposed to them, and can later choose which tools you like 
> and turn off the others.
> 
> Eric
> 
> >>> Felix Dorner <[EMAIL PROTECTED]> seems to think that:
> >>
> >>
> >>That's the because of semantic stickyfunc mode. Try M-x 
> >>global-semantic-stickyfunc-mode.
> >>  
> >>
> >
> >OK thanks. With that, the header-line disappeared.
> >I guess it appeared because I have 
> (semantic-load-enable-code-helpers)
> >(as in the cedet INSTALL file), do I really need this?
> >
> >another artifact that appeared yesterday too was an overline right 
> >above a class body, just like this:
> >
> >__
> >class TestSocket extends Socket{...
> >
> >
> >and a similar overline right above the main method of that class
> >
> >So what are those lines meant for?
> >Felix
> >
> 
> -- 
>   Eric Ludlam: [EMAIL PROTECTED], 
> [EMAIL PROTECTED]
>Home: http://www.ludlam.netSiege: www.siege-engine.com
> Emacs: http://cedet.sourceforge.net   GNU: www.gnu.org
> 

RE: Problem with nqmacs + jdee 2.3.5

[Nascif Abousalh-Neto]

I just tried it. ECB looks very nice too! 

> -Original Message-
> From: Ping Liang [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 04, 2005 12:29 PM
> To: jde-users
> Subject: Re: Problem with nqmacs + jdee 2.3.5
> 
> I found the cause of these problems. I still had jdee 
> 2.3.4beta5 directory in my site-lisp directory.  As soon as I 
> removed that, the problems I mentioned went away.
> 
> Thanks anyways.
> 
> On Thu, 3 Mar 2005 10:24:17 -0500, Ping Liang 
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > I decided to use nqmacs to take advantage of the new emacs 
> features it 
> > provides.  Since it does not work with jdee 2.3.4beta5 that I was 
> > using, I also upgraded jdee to 2.3.5.  After this, jdee 
> behaves quite 
> > differently.  To name a few,
> > 
> > 1) I noticed that jdb menu was not in the menu bar anymore.  I 
> > installed jde-usage and it was not there either.  Functions 
> are still 
> > defined as I can still use them but...
> > 
> > 2) I have an entry in my .emacs to add my own style, something like 
> > indenting only by 2 characters, etc.  It does not work any more. It 
> > seems that all are default values.  What I do is (add-hook 
> > 'jde-mode-hook 'my-jde-mode-hook).
> > 
> > 3) The key binding for jdee is not longer there.  For 
> example, C-c C-v 
> > Cy would bring me to the definition of a method/class/variable.  No 
> > more.  However, things like jde-open-class-source would work if I 
> > execute it from M-x.
> > 
> > While I can easily switch back to the old setup, the new 
> emacs is just 
> > too attractive to give up.  Anybody has the same 
> experiences? Any help 
> > would be appreciated.
> > 
> > Regards,
> > 
> > Ping
> >
> 

RE: code completion from noncompiled classes

[Nascif Abousalh-Neto]

Hi Fredick,

You can look at CEDET's Semantic "intelissense" feature, described at 
http://cedet.sourceforge.net/intellisense.shtml

This implementation works only for files you have previously loaded in an Emacs 
buffer (so it would not be useful for the JDK classes, unless you manually 
visit all the source files) but it provides "true" code completion like 
jde-complete - without requiring compiled classes.

There are also "poor man" alternatives, that don't provide true code completion 
but make up for that in speed. I use dabbrev-expand a lot, and once you get 
used to it it can be quite useful. 

I also played a little with predictive mode 
(http://www.emacswiki.org/cgi-bin/wiki/PredictiveMode) using a dictionary made 
of Java keywords and JDK class names. The latest version has support for 
regular-expression based dictionary switching, which perhaps could be expanded 
with some info from Semantic to create a more useful tool. The way predictive 
works (offering alternatives as you type) is very interesting, but it 
definetely needs to be better tied up to the Java syntax to be more useful.

Regards,
  Nascif



> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 02, 2005 11:24 PM
> To: Fredrik Skeel Loekke
> Cc: jde@sunsite.dk
> Subject: code completion from noncompiled classes
> 
> Fredrik Skeel Loekke writes:
>  > is it possible to use code completion from noncompiled classes?
>  > 
> 
> It's possible but it would require a major coding effort to 
> enhance the JDEE to do this.
> 
> Paul
> 
> 

Continous Testing

[Nascif Abousalh-Neto]

Hi all,

I recently learned about this Eclipse plugin: 
http://pag.csail.mit.edu/continuoustesting/
The idea of this plugin is to use idle cycles to run your unit testcases - as 
soon as you finish a change, your unit testcases would be executed (perhaps 
just the ones for that class) to give you instant feedback on any bug you might 
have introduced.

I was thinking on how to implement that for Emacs/JDEE. Perhaps an extension or 
hook for flymake could be used, together with a call to jde-eval - once we know 
the class is syntatically correct, we trigger the execution of the testcases. 
Or maybe a hook into semantics, since it also seems to do work in the 
background now.

What do you think? Any ideas?

/Nascif

JDEE extension pages in the Emacs Wiki

[Nascif Abousalh-Neto]

I created pages in the Emacs Wiki for some of the extensions I wrote, plus the 
"usages" plugin.

Regards,
  Nascif


> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 19, 2005 11:38 PM
> To: Nascif Abousalh-Neto
> Cc: jde@sunsite.dk
> Subject: [ANN] jde-lint
> 
> Hi Nascif,
> 
> I have added jde-lint.el to the Contributed Software page on 
> the JDEE website. I think it would be a good idea for you to 
> add it to the JDEE Wiki page as well to make sure that JDEE 
> users are aware of it. 
> 
> If you don't mind, I'd like to consider the jde-lint.el 
> package for inclusion in the JDEE distribution as well.
> 
> Thanks for providing this valuable contribution.
> 
> Regards,
> 
> Paul
> 
> Nascif Abousalh-Neto writes:
>  > Hi,
>  >
>  > I created a small packaged called jde-lint.el that 
> provides an interface between JDEE (http://jdee.sunsite.dk/), 
> and Lint4j (http://www.jutils.com/). 
>  >
>  > Lint4j ("Lint for Java") is a static Java source code 
> analyzer that detects locking and threading issues, 
> performance and scalability problems, and checks complex 
> contracts such as Java serialization by performing type, data 
> flow, and lock graph analysis.
>  >
>  > This package uses the information from your JDE project 
> (sourcepath, classpath and package name) to run the lint4j 
> tool and present the result in a compilation buffer.
>  >
>  > You can get it at: http://home.nc.rr.com/nascifandelaine/emacs.html
>  >
>  > Regards,
>  >   Nascif
>  >
>  > PS: Paul, what would you recommend as the best way to keep 
> links for contributed packages like this one? Is it OK to add 
> a new page under the JDEE page in the Emacs Wiki? I think it 
> would be better to have it all under the official JDEE page 
> but using the EmacsWiki decentralize the efforts.
>  > 
> 
> 

[ANN] jde-lint

[Nascif Abousalh-Neto]

Hi,

I created a small packaged called jde-lint.el that provides an interface 
between JDEE (http://jdee.sunsite.dk/), and Lint4j (http://www.jutils.com/). 

Lint4j ("Lint for Java") is a static Java source code analyzer that detects 
locking and threading issues, performance and scalability problems, and checks 
complex contracts such as Java serialization by performing type, data flow, and 
lock graph analysis.

This package uses the information from your JDE project (sourcepath, classpath 
and package name) to run the lint4j tool and present the result in a 
compilation buffer.

You can get it at: http://home.nc.rr.com/nascifandelaine/emacs.html

Regards,
  Nascif

PS: Paul, what would you recommend as the best way to keep links for 
contributed packages like this one? Is it OK to add a new page under the JDEE 
page in the Emacs Wiki? I think it would be better to have it all under the 
official JDEE page but using the EmacsWiki decentralize the efforts.

RE: Problem loading JDE in Emacs CVS

[Nascif Abousalh-Neto]

I upgraded to the SourceForge cc-mode, and after a lot of experiments, this is 
what worked for me:

(add-to-list 'load-path (expand-file-name "~/emacs/cc-mode-5.30.9"))
...
(load "cc-defs")
(load "cc-fonts")
(defvar java-font-lock-keywords-3 nil)
(require 'jde)

Very ugly, I know... :-(

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, January 08, 2005 7:09 AM
> To: Nascif Abousalh-Neto
> Cc: jde@sunsite.dk
> Subject: Re: Problem loading JDE in Emacs CVS
> 
> Nascif Abousalh-Neto wrote:
> 
> > Hi Martin,
> > 
> > Thanks for the feedback, I am still battling it.
> > Do you have the latest cc-mode in your system, or are you 
> using the one that comes with Emacs?
> 
> I'm using cc-mode coming with Emacs.
> I've Cygwin installed and use the makefiles to build the 
> CEDET and JDEE.
> 
> Martin
> 
> > 
> > Regards,
> >   Nascif
> > 
> > 
> >>-Original Message-
> >>From: Martin Schwamberger [mailto:[EMAIL PROTECTED]
> >>Sent: Friday, January 07, 2005 7:59 AM
> >>To: Nascif Abousalh-Neto
> >>Cc: jde@sunsite.dk
> >>Subject: Re: Problem loading JDE in Emacs CVS
> >>
> >>Hi Nascif,
> >>
> >>I'm using this emacs build together with JDEE 2.3.5.
> >>I don't experience this kind of problem.
> >>java-font-lock-keywords-3 is defined.
> >>Did you recompile CEDET (and the other packages, JDEE depends on)?
> >>
> >>Martin
> >>
> >>Nascif Abousalh-Neto wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>I am trying out the Emacs build from CVS  for Windows
> >>
> >>(http://www.crasseux.com/emacs/, posted by Martin Schwamberger, 
> >>thanks!) and I am having some problems.
> >>
> >>>When I try to load JDE, I get the following error:
> >>>
> >>>Debugger entered--Lisp error: (void-variable
> >>
> >>java-font-lock-keywords-3)
> >>
> >>>  jde-java-font-lock-keywords(nil)
> >>>  jde-java-font-lock-setup-keywords()
> >>>  require(jde-java-font-lock)
> >>>  eval-buffer(#> nil "jde" nil t)  ;;; 
> Reading at 
> >>> buffer position 2829
> >>>  
> >>
> >>load-with-code-conversion("c:/home/emacs/jde-2.3.5/lisp/jde.el
> >>" "jde" nil t)
> >>
> >>>  require(jde)
> >>>  eval-buffer(# nil "~/.emacs" nil t)  ;;; 
> Reading at 
> >>> buffer position 15813  load-with-code-conversion("c:/home/.emacs" 
> >>> "~/.emacs" t t)  load("~/.emacs" t t)
> >>>
> >>>
> >>>Any ideas? I already removed all the .elc and byte-compiled again.
> >>>
> >>>Regards,
> >>>  Nascif
> >>>
> >>>
> >>>
> >>
> > 
> 

RE: Problem loading JDE in Emacs CVS

[Nascif Abousalh-Neto]

Hi Martin,

Thanks for the feedback, I am still battling it.
Do you have the latest cc-mode in your system, or are you using the one that 
comes with Emacs?

Regards,
  Nascif

> -Original Message-
> From: Martin Schwamberger [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 07, 2005 7:59 AM
> To: Nascif Abousalh-Neto
> Cc: jde@sunsite.dk
> Subject: Re: Problem loading JDE in Emacs CVS
> 
> Hi Nascif,
> 
> I'm using this emacs build together with JDEE 2.3.5.
> I don't experience this kind of problem.
> java-font-lock-keywords-3 is defined.
> Did you recompile CEDET (and the other packages, JDEE depends on)?
> 
> Martin
> 
> Nascif Abousalh-Neto wrote:
> 
> > Hi,
> > 
> > I am trying out the Emacs build from CVS  for Windows 
> (http://www.crasseux.com/emacs/, posted by Martin 
> Schwamberger, thanks!) and I am having some problems.
> > When I try to load JDE, I get the following error:
> > 
> > Debugger entered--Lisp error: (void-variable 
> java-font-lock-keywords-3)
> >   jde-java-font-lock-keywords(nil)
> >   jde-java-font-lock-setup-keywords()
> >   require(jde-java-font-lock)
> >   eval-buffer(#> nil "jde" nil t)
> >   ;;; Reading at buffer position 2829
> >   
> load-with-code-conversion("c:/home/emacs/jde-2.3.5/lisp/jde.el
> " "jde" nil t)
> >   require(jde)
> >   eval-buffer(# nil "~/.emacs" nil t)
> >   ;;; Reading at buffer position 15813
> >   load-with-code-conversion("c:/home/.emacs" "~/.emacs" t t)
> >   load("~/.emacs" t t)
> > 
> > 
> > Any ideas? I already removed all the .elc and byte-compiled again.
> > 
> > Regards,
> >   Nascif
> > 
> > 
> > 
> 

Problem loading JDE in Emacs CVS

[Nascif Abousalh-Neto]

Hi,

I am trying out the Emacs build from CVS  for Windows 
(http://www.crasseux.com/emacs/, posted by Martin Schwamberger, thanks!) and I 
am having some problems.
When I try to load JDE, I get the following error:

Debugger entered--Lisp error: (void-variable java-font-lock-keywords-3)
  jde-java-font-lock-keywords(nil)
  jde-java-font-lock-setup-keywords()
  require(jde-java-font-lock)
  eval-buffer(#> nil "jde" nil t)
  ;;; Reading at buffer position 2829
  load-with-code-conversion("c:/home/emacs/jde-2.3.5/lisp/jde.el" "jde" nil t)
  require(jde)
  eval-buffer(# nil "~/.emacs" nil t)
  ;;; Reading at buffer position 15813
  load-with-code-conversion("c:/home/.emacs" "~/.emacs" t t)
  load("~/.emacs" t t)


Any ideas? I already removed all the .elc and byte-compiled again.

Regards,
  Nascif

Minor problem with jde-import-kill-extra-imports

[Nascif Abousalh-Neto]

It seems this command does not skip comment areas. 

I got an "Avoid unused imports such as 'xyz" from a PMD report and when I used 
jde-import-kill-extra-imports to remove them, it didn't remove anything. Turns 
out that the imported class name was in one of my comments. I removed it and 
jde-import-kill-extra-imports worked fine.

Thanks,
  Nascif

RE: Auto-format code to width <= 80

[Nascif Abousalh-Neto]

Hi Mark, 

For a different approach, take a look at jde-jalopy.el at 
http://home.nc.rr.com/nascifandelaine/emacs.html

It integrates Jalopy, an open-source Java pretty-printer, with JDE. It allows 
you can customize a lot of different aspects of your code "appearance" (brace 
positioning, use of spaces and empty lines, etc.) and maximum line length is 
one. It will reformat the code to satisfy your specifications taking Java 
syntax into account.

Regards,
  Nascif


> -Original Message-
> From: Troy Daniels [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, December 14, 2004 12:47 PM
> To: Mark D. Hansen
> Cc: [EMAIL PROTECTED]
> Subject: Re: Auto-format code to width <= 80
> 
> At 05:34 PM 12/14/2004 +, Jason Rumney wrote:
> 
> >Mark D. Hansen wrote:
> >
> >>Can anyone tell me how to configure emacs/jde so that my java code 
> >>will auto-format to have column width 80?
> >>
> >>Thanks,
> >>
> >>Mark
> >>
> >auto-fill-mode
> 
> That works, but if you're not paying attention, you can get 
> code that looks like this:
> 
> object.method(someArg,
>  "a rather
> long string",
>   new
> AClassWithAReallyLongName(3));
> 
> While this meets the requirement of not having anything 
> beyond column 80, it's probably not what you actually want.  
> Especially since the compiler won't accept the string.
> 
> The various options other people have been suggesting are 
> probably better.
> 
> Troy
> 
> 
> 
> 
> 
> Troy Daniels
> [EMAIL PROTECTED]
> 781-273-3388 x218
> 
> 

RE: _Long_ pause after each new directory is noticed. . .

[Nascif Abousalh-Neto]

I am having a similar problem, but it is not deterministic. Had it yesterday 
but can't reproduce today.
Using ECB 2.30 and JDE 2.3.4.

Debug-on-error doesn't work for this one, and the long breaks are *very* 
disruptive.

Any idea on how to debug something like that?

> -Original Message-
> From: Henry S. Thompson [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, December 07, 2004 10:34 AM
> To: jde
> Subject: _Long_ pause after each new directory is noticed. . .
> 
> Just upgraded both jde and ecb (can't tell which is the problem,
> sorry) to latest versions (ecb 2.30.1 and jcb 2.3.4)
> 
> Whenever I read or save a .java file to a particular package 
> directory for the first time in a given session, xemacs goes 
> away for a long (several minutes) time.  It's not responsive 
> to Ctrl-G during this time.
> 
> Not sure this is new, but it seems worse. . .
> 
> Any clues?
> 
> ht
> --
>  Henry S. Thompson, HCRC Language Technology Group, 
> University of Edinburgh
>  Half-time member of W3C Team
> 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
> 131 650-4440
> Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
>URL: http://www.ltg.ed.ac.uk/~ht/ [mail 
> really from me _always_ has this .sig -- mail without it is 
> forged spam]
> 

RE: Investigating quickfix functionality

[Nascif Abousalh-Neto]

Hi Kai,

Great job!

Take a look at flymake.el and jde-flymake.el. Together they provide on-the-fly 
compilation to JDEE. This makes for a nice complement to your module; you 
wouldn't have to do a full compile to get the compilation buffer in order to 
call qfix. As soon as flymake kicks in and detects the error, you would have 
enough information to decide which quick fixes to offer. You might have to make 
changes on how you detect errors since I believe jikes error messages might be 
slightly different then the ones from javac.

I think this combination would get the whole environment even closer to what 
you found in Eclipse.

Regards,
  Nascif 

> -Original Message-
> From: Kai Grossjohann [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, November 28, 2004 7:03 AM
> To: [EMAIL PROTECTED]
> Subject: Investigating quickfix functionality
> 
> I had been using Eclipse for some time a year ago.  One thing 
> I really liked about it was the quickfix functionality.  When 
> the compiler found an error in your source code, you could 
> hit Ctrl+1 to pop up a little menu which suggested some remedies.
> 
> Because I missed it so much, I investigate whether it would 
> be possible to get this in Emacs, as well.  It seems it would 
> be possible in principle.
> 
> This version only knows two kinds of errors: unreported 
> exception, and cannot resolve symbol class Foo.
> 
> I'd appreciate any comments or help or patches.
> 
> What do people think?
> 
> Kai
> 
> 

JDEE Wiki?

[Nascif Abousalh-Neto]

Hi Paul,

Have you considered hosting a Wiki for the JDEE? I think it would cut a lot on basic 
questions, as it would be a more friendly way for JDEE users to share and organize 
their knowledge, tips, etc. It would definetely be more effective than browsing the 
mailing list.

A Wiki with attachments capabilities (like JSPWiki) would also make it easier for 
users to post their own patches, plugins, etc.

Regards,
  Nascif

-Original Message-
From: Jeff Greif [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 17, 2004 2:03 PM
To: Anakreon; [EMAIL PROTECTED]
Subject: Re: Syntax highlighting problem

See  http://www.mail-archive.com/[EMAIL PROTECTED]/msg07761.html and the other 
messages of that thread.
Jeff
- Original Message -
From: "Anakreon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 17, 2004 10:43 AM
Subject: Syntax highlighting problem


> Version info
> 
> emacs:GNU Emacs 21.3.1
> jde:the latest stable release
> OS:Linux
>
> The problem is that after the firts java file is loaded, any other java
file I load
> is displayed without syntax highlighting.
>
> If the jde is not loaded at startup, then this behaveur does not apear.
>
> Anakreon.

RE: Feedback needed on w3m support

[Nascif Abousalh-Neto]

I had this same problem; we solved it by configuring JDEE to create the temporary 
pages in a directory relative to the user's home, something like ~/tmp, instead of the 
default /tmp.

Regards,
  Nascif

> -Original Message-
> From: Heinz-Dieter Conradi [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 05, 2004 3:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Feedback needed on w3m support
> 
> hi,
> 
> without knowing anything about the problems involved, i would 
> like to point out a potential problem with local files which 
> has bitten me in the
> past: the local files are usually not writeable for other 
> users. this is a problem when more than one person is working 
> on the same workstation.
> 
> although i like the frame display too, i would probably go 
> for using non-local files without frames,
> 
> heinz-dieter conradi
> 
> 

RE: refactoring in jdee

[Nascif Abousalh-Neto]

I think this might be a problem for refactoring support, as you have to manipulate the 
source code on the abstract syntax tree level - a refactoring is usually implemented 
by applying a transformation to the AST, then generating code from the transformed 
tree or affected tree section (for all the files affected).

Since you have to correlate the source code with the AST, I don't think that the 
byte-code would have enough information (maybe it has with the line numbers from the 
debug information, not sure). Maybe for some simple refactorings it would be 
sufficient, but for example for extract method, the input to the refactoring is a 
region in the source code - not a symbol name, but a sequencial group of lines. One 
would have to be able to map that back to the structure created from the byte-code.

The documentation of CEDET (http://cedet.sourceforge.net/semantic.shtml) describes the 
following among the new features of the Semantic 2.0 package:

Bison ported to Emacs 
  David Ponce has ported Bison to Emacs Lisp. Languages supported via the new wisent 
parser will run faster. New languages will be easier to support as you can run a handy 
script to port directly from .y sources.

Maybe the new parser could provide the more advanced data structures required to 
support refactoring.

> -Original Message-
> From: Suraj Acharya [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 01, 2004 1:10 PM
> To: Nascif Abousalh-Neto
> Cc: [EMAIL PROTECTED]
> Subject: Re: refactoring in jdee
> 
> jde-usages doesn't parse any source at all, it only looks at 
> byte-code from classes in jde-global-classpath.
> 
> Suraj
> 
> On Fri, 1 Oct 2004 12:36:57 -0400, Nascif Abousalh-Neto 
> <[EMAIL PROTECTED]> wrote:
> > Another tool to consider is FreeFactor. It is in 
> SourceForge, and it is already integrated with Emacs.
> > It is still alpha, but is a good start for a true refactoring tool.
> > 
> > http://sourceforge.net/projects/freefactor.
> > 
> > A true refactoring tool needs access to the full syntactic 
> tree of the source code - not just method signatures, but 
> also method bodies. Does semantic support that? How about jde-usages?
> >
> 

RE: refactoring in jdee

[Nascif Abousalh-Neto]

Another tool to consider is FreeFactor. It is in SourceForge, and it is already 
integrated with Emacs.
It is still alpha, but is a good start for a true refactoring tool. 

http://sourceforge.net/projects/freefactor. 

A true refactoring tool needs access to the full syntactic tree of the source code - 
not just method signatures, but also method bodies. Does semantic support that? How 
about jde-usages?

RE: maven contribution

[Nascif Abousalh-Neto]

That would be a nice extension to JDE.

Would it be possible to extend the Ant Server or the Compile Server to make them 
generic enough to run Maven, or other Java-based tools like PMD, CheckStyle, etc., 
etc? I found that the code in AntServer.java and CompileServer.java is very similar; 
the differences could be refactored to a separate file, and a generic interface be 
defined. New Java-based plugins could implement this interface and thus be added to 
the JDE "server" support (through the BeanShell), instead of calling new JVMs on 
demand.

Regards,
  Nascif



> -Original Message-
> From: Dominik Dahlem [mailto:[EMAIL PROTECTED] 
> Sent: Friday, September 24, 2004 7:15 AM
> To: [EMAIL PROTECTED]
> Subject: maven contribution
> 
> Hi all,
> 
> I'm curious to know whether there are plans to add 
> jde-maven.el under the hood of JDEE? There are two versions 
> of jde-maven.el around [1,2] but they have not been 
> contributed to the JDE CVS.
> 
> 
> Thanks,
> Dominik
> 
> 
> [1]-http://lists.gnu.org/archive/html/gnu-emacs-sources/2004-0
> 5/msg00032.html
> [2]-http://www.mail-archive.com/[EMAIL PROTECTED]/msg06674.html
> 
> 
> --
> Dominik Dahlem <[EMAIL PROTECTED]>
> ---
> Trinity College Dublin
> Department of Computer Science,
> Dublin 2, Ireland
> 
> tel: (+353) 1-608 1539
> fax: (+353) 1-677 2204
> www: http://www.cs.tcd.ie/Dominik.Dahlem/
> ---
> 
> 
> 
> 
> 

Jde-ant-enable-find

[Nascif Abousalh-Neto]

Is this variable (Jde-ant-enable-find) preserved between project switches? 
I always get the value set int the first project I load, even after switching to a 
second project where it is set to a different value.

/Nascif

RE: flymake / jde-flymake problem

[Nascif Abousalh-Neto]

Thanks Milan!

Glad to see it is working for you now. I just updated the latest version to my web 
site,
Plus a link to the PMD plugin in SourceForge.

Regards,
  Nascif


-Original Message-
From: Milan Zimmermann [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 17, 2004 10:37 PM
To: Nascif Abousalh-Neto
Cc: [EMAIL PROTECTED]
Subject: Re: flymake / jde-flymake problem


Nascif,

The modified version works just beautifully! ECB+JDE+jde-flymake ..  great 
environment, thanks!

(I have been using JDE a long time ago but recently only IDEA at work and 
Eclipse at home, but Eclipse, at least on Linux, is so slow now that it 
became unbearable. I am gonna try your PMD plugin in the next few days as 
well, but still have lots to learn on JDE setup + project building.)

Thanks again, Milan

On June 17, 2004 02:44 pm, Nascif Abousalh-Neto wrote:
> Hey Milan,
>
> I think I got a bug - something that shouldn't be working but probably 
> did because of my environment. Give it a try and see if this version 
> works for you.
>
> /Nascif
>
> -Original Message-
> From: Milan Zimmermann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 17, 2004 1:57 AM
> To: Nascif Abousalh-Neto; [EMAIL PROTECTED]
> Subject: Re: flymake / jde-flymake problem
>
>
> Nascif,
>
> Thanks for your detail answer. This is on is Linux SuSE 8.1 Emacs v. 
> 21.2.1 ... I  enabled debug-on-error, please see results and comments 
> on you notes
> inline:
>
> On June 16, 2004 10:23 pm, Nascif Abousalh-Neto wrote:
> > Hi Milan,
> >
> > I searched for this error message in both flymake.el and 
> > jde-flymake.el and I was not able to find it.
>
> i have looked in the message window and this the message seems from 
> jde .. which seems weird as i never saw it in any other situation 
> except trying any flymake command (even mode):
>
>
> # On flymake-mode, i get:
>
> Debugger entered--Lisp error: (file-error "Opening directory" "not a  
>directory"  
>"/home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/uti
>l/en
>tityModelUMLToXML/UMLEntities2Hibernate.java")
>
> 
>directory-files("/home/mzimmermann/projects/eclipse3workspace/airliftj/src/
>airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java")
>
> 
>jde-find-project-file("/home/mzimmermann/projects/eclipse3workspace/airlift
>j/src/airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java")
> flymake-jde-jikes-java-init(#)
> flymake-start-syntax-check(#)
> flymake-start-syntax-check-for-current-buffer()
>   flymake-mode-on()
>   flymake-mode()
> * call-interactively(flymake-mode)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)
>
>  In Message window:
>
> Loading /home/mzimmermann/projects/eclipse3workspace/airliftj/prj.el
> (source)...done [2 times]
> jde-find-project-file: Opening directory: not a directory,  
>/home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/util
>/ent
>ityModelUMLToXML/UMLEntities2Hibernate.java
>
> # On "flymake-start-syntax-check-for-current-buffer" i get:
>
> Debugger entered--Lisp error: (file-error "Opening directory" "not a  
>directory"  
>"/home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/uti
>l/en
>tityModelUMLToXML/UMLEntities2Hibernate.java")
>
> 
>directory-files("/home/mzimmermann/projects/eclipse3workspace/airliftj/src/
>airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java")
>
> 
>jde-find-project-file("/home/mzimmermann/projects/eclipse3workspace/airlift
>j/src/airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java")
> flymake-jde-jikes-java-init(#)
> flymake-start-syntax-check(#)
> flymake-start-syntax-check-for-current-buffer()
> * call-interactively(flymake-start-syntax-check-for-current-buffer)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)
>   recursive-edit()
>   byte-code("Ãâ !ÃËÃâ ÃËÃË!ÃË\nÃÆ?
>
> > I wonder if it was not a problem during
> > configuration, given that it is quite complex. In order to narrow 
> > down the possibilities, I would suggest the following: 1) enable 
> > debug-on-error to get a full trace;
>
> ok thanks
>
> > 2) make sure you are using the correct version of flymake - not the 
> > official one (0.2) but the one from CVS: 
> > http://cvs.sourceforge.net/viewcvs.py/flymake/flymake/
>
> yes, i use the CVS version ...
>
> > 3) double check the customization
>
> i believe i have items 1-5 correct (did not do the highlighting
> customization) there is only one variable to customize, is that 
> correct?
>
> I am attacthing my prj.el - not that I would want you to spend time 
> debugging my setup but just in case ...
>
> Thanks again, Milan

ANN: pmd-emacs

[Nascif Abousalh-Neto]

Hi all,

Just posted a new version of the Emacs plug-in for PMD (get it from SourceForge, see 
links below). 

PMD is a syntatic code analyser similar to CheckStyle - but with a focus more towards 
potential problems (e.g. unused variables) then syntatic guideline violations. It is 
also quite easy to customize with new rules.

It can be used as "lint", providing rule violations in a compile buffer and allowing 
you to jump directly to the associated source code line.

Happy Hacking,
  Nascif


-Original Message-
From: SourceForge.net [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 17, 2004 10:09 AM
To: [EMAIL PROTECTED]
Subject: [SourceForge.net Release] pmd : pmd-emacs


Project: PMD  (pmd)
Package: pmd-emacs
Date   : 2004-06-17 09:09

Project "PMD" ('pmd') has released the new version of package 'pmd-emacs'. You can 
download it from SourceForge.net by following this link: 

or browse Release Notes and ChangeLog by visiting this link: 
 

You receive this email because you requested to be notified when new versions of this 
package were released. If you don't wish to be notified in the future, please login to 
SourceForge.net and click this link: 

If you lost your SourceForge.net login name or password, refer to this document: 


Note that you may receive this message indirectly via one of your mailing list 
subscriptions. Please review message headers before reporting unsolicited mailings.

RE: flymake / jde-flymake problem

[Nascif Abousalh-Neto]

Hi Milan,

I searched for this error message in both flymake.el and jde-flymake.el and I was not 
able to find it. I wonder if it was not a problem during configuration, given that it 
is quite complex. In order to narrow down the possibilities, I would suggest the 
following:
1) enable debug-on-error to get a full trace;
2) make sure you are using the correct version of flymake - not the official one (0.2) 
but the one from CVS:
http://cvs.sourceforge.net/viewcvs.py/flymake/flymake/
3) double check the customization

With the stack trace of the error it should be easier to find out what is happening. I 
use jde-flymake on a daily basis. My environment is Windows NT with GNU Emacs 21.1. 
What is yours? It could be also an environment problem, Windows vs. *nix or Emacs vs. 
XEmacs.

Regards,
  Nascif


-Original Message-
From: Milan Zimmermann [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 16, 2004 1:30 AM
To: [EMAIL PROTECTED]
Subject: flymake / jde-flymake problem


Hello,

I am wondering if anyone using flymake and jde-flymake here. I installed both  
following the instaructions in jde-flymake customized variables etc, but when 
I try to 

M-x flymake-mode

on java file (e.g. MyClass.java)

I get a message:

Opening directoty: Not a directory, path-to-my-class/MyClass.java

I am getting the same message trying to use other flymake commands (such as 
flymake-start-syntax-check-for-current-buffer.

Anyone has an idea what could be wrong?

Thanks Milan

RE: Real time syntax checking ?

[Nascif Abousalh-Neto]

Also note that Flymake can be used to validate XML files on the fly, even ones without 
a formal DTD.
*Very* convenient when playing with Ant build.xml files.

To enable XML validation, you will need the XMLStar tool from this site: 
http://xmlstar.sourceforge.net/

Regards,
  Nascif


-Original Message-
From: Suraj Acharya [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 30, 2004 3:32 AM
To: Ding Lei
Cc: JDE Mailing List
Subject: Re: Real time syntax checking ?


The closest you can get is jde-flymake
(http://home.nc.rr.com/nascifandelaine/emacs.html)
which runs jikes frequently and parses its error and warning messages.

On a fast machine this works surprisingly well.

Suraj

On Sun, 30 May 2004 12:55:50 +0800, Ding Lei <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> Is JDEE possible to do real time syntax checking while coding 
> ? I first found this feature in Eclipse, it really saves lots of time.
> Anyway ... even If the answer is NO, i will be still be using 
> emacs/jde, really love it so much :)
> Thanks.
> 
> --
> 
><<<:   D i n gL e i   ::>>
>  ||  ||
>  || Ext: 8106||
>  || Email:||
>  || Dept. Of Technology/Engineering  ||
>  || Embedded Information Services Inc.   ||
>  ||  ||
> <((= )>>>
> 
> After a number of decimal places, nobody gives a damn.
>

Problems with ResourceBundle

[Nascif Abousalh-Neto]

Hi,

I am developing an internationalized GUI. When I launch my application from the shell 
prompt using a script wrapper, it can find the resource bundle, no problem. When I run 
it from JDEE using the jde-run command, I get :

java.util.MissingResourceException: Can't find bundle for base name 
com.sas.analytics.irp.client.resources, locale en_US
at 
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:804)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:661)
at 
com.sas.analytics.irp.client.util.ResourceProvider.init(ResourceProvider.java:41)

I checked the classpath and it is exactly the same, and the resource bundle file is 
right there where I expect it (inside the main jar file). 
Any idea what could be the difference between launching from a script and launching 
from JDEE that would explain this difference in behavior?

TIA,
  Nascif

jde-import-sort

[Nascif Abousalh-Neto]

When I try to use the JDE wizards to create a new class, the code generation fails 
(creates only part of the class) and I get the following error message:

jde-import-sort: Semantic Java parser not found. JDE 2.1.6-beta24+
 needed.

I looked around and it seems that the problem is with the call to jde-import-sort, 
which relies on a deprecated variable in sematic:
>From jde-import.el:
  (or (and (local-variable-p 'semantic-toplevel-bovine-table (current-buffer))
   (symbol-value 'semantic-toplevel-bovine-table))

>From semantic.el (latest from new CEDET package:)
(defvar semantic--parse-table nil
  "Variable that defines how to parse top level items in a buffer.
This variable is for internal use only, and its content depends on the
external parser used.")
(make-variable-buffer-local 'semantic--parse-table)
(semantic-varalias-obsolete 'semantic-toplevel-bovine-table
'semantic--parse-table)

Regards,
  Nascif


-- 
Nascif A. Abousalh-Neto
Inventory Replenishment Planning Java Architect
SAS Institute, Inc.
100 SAS Campus Dr, R4113
Cary NC 27513-8617
Tel 919-531-10123

RE: JDE 2.3.4beta3: strange "overlining"

[Nascif Abousalh-Neto]

Hi Petter,

This is a behavior in the Senator package that seems to be enabled by default in the 
new CEDET.
On the Emacs menu, select "Senator" and then "Modes". You will see that *all* of them 
are enabled. 
Disable "Show Tag Boundaries" and "Highlight Tags by Attribute". I disabled everything 
actually.
Regards,
  Nascif

-Original Message-
From: Petter Måhlén [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 11, 2004 7:16 AM
To: [EMAIL PROTECTED]
Subject: JDE 2.3.4beta3: strange "overlining"


Hi,

I'm getting the weird effect shown in the attached GIF using JDE 2.3.4beta3 and 
cedet1.0beta2 on Emacs 21.3. All non-public methods are 'overlined', which is really 
not pleasant. I guess it's some kind of highlighting of non-public methods that has 
gone wrong - does anybody know of a configuration setting to modify this behaviour or 
is it possibly a bug?

/ Petter

RE: W3m binary for windows

[Nascif Abousalh-Neto]

I did, but they are 4-5 years old.
I was able to compile the latest w3m (had to install and compile a garbage collection 
package first, and change my configuration so that the gc.h include file could be 
found by gcc). 

Emacs-w3c works fine, a really nice extension to JDEE. One less reason to leave Emacs 
:-)

Regards,
  Nascif

-Original Message-
From: Suraj Acharya [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 26, 2004 1:23 PM
To: Nascif Abousalh-Neto
Cc: [EMAIL PROTECTED]
Subject: Re: W3m binary for windows


Take a look at http://www.w3m.org/. It has cygwin binaries for windows.

Suraj

On Mon, 26 Apr 2004 10:29:40 -0400, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote:
> 
> Hi there,
> 
> I have been reading about w3m + Emacs and that some lucky guys out 
> there are already browsing their Javadoc pages with it inside Emacs. 
> How cool is that? :-) I would like to do the same as well, but I am 
> having a hard time collecting all the pieces to build w3m on my 
> WindowsXP + Cygwin box. I found some really old (1999) Windows 
> binaries which don't seem to work.
> 
> Does anybody has a more recent version available? And isn't this 
> package useful enough to be included with the default JDE distribution 
> - or at least to have a pointer to it in the JDEE documentation?
> 
> Regards,
>   Nascif
> 
>

W3m binary for windows

[Nascif Abousalh-Neto]

Hi there, 

I have been reading about w3m + Emacs and that some lucky guys out there are already 
browsing their Javadoc pages with it inside Emacs. How cool is that? :-) I would like 
to do the same as well, but I am having a hard time collecting all the pieces to build 
w3m on my WindowsXP + Cygwin box. I found some really old (1999) Windows binaries 
which don't seem to work.

Does anybody has a more recent version available? And isn't this package useful enough 
to be included with the default JDE distribution - or at least to have a pointer to it 
in the JDEE documentation?

Regards,
  Nascif

ANN: jde-flymake update

[Nascif Abousalh-Neto]

Hi all,

I incorporated enhancements from Christopher (thanks!) and tested (in Emacs only, 
there may be some problems with Xemacs) with the latest version of flymake in CVS, 
which incorporates the patches necessary to use with jde-flymake. 

I also created a new module with a helper function that makes flymake more convenient 
to use with the keyboard.

Get the new version at: http://home.nc.rr.com/nascifandelaine/emacs.html

Enjoy,
  Nascif

PS: I had many jde-jalopy extensions sent to me recently, but I am still working on 
the merging. Thanks to all that sent extensions and sorry for the delay. 

RE: jde-flymake

[Nascif Abousalh-Neto]

Hi,

Send me the changes and I will be happy to incorporate them to the official version.

Regards,
  Nascif

PS: I had to put the jde-jalopy development in the back burner for a while, still 
trying to get something that works both on Emacs and Xemacs... I am looking into using 
jde-jeval instead of launching a new JVM.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 31, 2004 3:54 AM
To: [EMAIL PROTECTED]
Subject: RE: jde-flymake




Hello,

I have made some little modification to have more customization and jde integration 
this package work fine with my emacs/jde configuration

RE: jde-flymake

[Nascif Abousalh-Neto]

http://www-124.ibm.com/developerworks/opensource/jikes/

-Original Message- 
From: Sandip Chitale [mailto:[EMAIL PROTECTED] 
Sent: Sat 3/13/2004 2:36 PM 
To: Nascif Abousalh-Neto; [EMAIL PROTECTED] 
Cc: 
Subject: RE: jde-flymake




Where to get jikes?

-Original Message-
From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004 6:51 AM
To: [EMAIL PROTECTED]
Subject: ANN: jde-flymake


Hi all,

I also posted an initial version of jde-flymake, which provides
extensions to Flymake (http://flymake.sourceforge.net/), an "on-the-fly
syntax checker for Emacs" created by Pavel Kobiakov.

Flymake comes with built-in support for Java but relies on Makefiles for
calling Jikes; this module relies instead on JDEE project variables,
removing the need to create Makefiles just for the purpose of using
Flymake.

NOTE: jde-flymake.el requires a patched version of flymake.el. The patch
have been submitted to the author. In the mean time you can get a
patched version on my download page.

Regards,
  Nascif

http://home.nc.rr.com/nascifandelaine/emacs.html

RE: jde-jalopy update

[Nascif Abousalh-Neto]

Hi Paul,

I will merge your changes and roll out a 1.4  version soon (but not too soon, I am a 
little swamped right now).
If time permits I will also roll out the Jalopy jar file into a .zip and make that a 
"true" JDEE plug-in.

Thanks for the new features!

Regards,
  Nascif




-Original Message-
From: Paul Landes [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 08, 2004 1:56 PM
To: Nascif Abousalh-Neto
Cc: [EMAIL PROTECTED]
Subject: ANN: jde-jalopy update


I knew I should have gotten this done sooner.  I did some hacking on this because I 
couldn't get Bob's code to work (at least under XEmacs).

Since the thing is in such a flux, I'm just going to attach what I have.  I started 
with what was on your site, Nascif.

Nascif Abousalh-Neto writes:
 > Hi all,
 > 
 > I uploaded version 1.3 of jde-jalopy.el, which incorporates the method 
 > jde-jalopy-buffer posted by Bob Schellink.  > Enjoy,
 >   Nascif
 > 
 > http://home.nc.rr.com/nascifandelaine/emacs.html


;;; jde-jalopy.el --- JALOPY interface for JDE

;; Copyright (C) 2002 Nascif A. Abousalh Neto

;; Author: Nascif A. Abousalh Neto 
;; Maintainer: Nascif A. Abousalh Neto <[EMAIL PROTECTED]>
;; Keywords: java, beautifier, pretty printer, tools
;; Time-stamp: <2002-12-04 00:48:50 nascif>
;; 
;; Version: 1.2
;;
;; This program is free software; you can redistribute it and/or modify ;; it under 
the terms of the GNU General Public License as published by ;; the Free Software 
Foundation; either version 1, or (at your option) ;; any later version.

;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY 
WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.  See the ;; GNU General Public License for more details.

;; A copy of the GNU General Public License can be obtained from the Free ;; Software 
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

;;; Commentary:
;; This package provides an interface from JDE (see http://jde.sunsite.dk/) to ;; 
Jalopy (see http://jalopy.sourceforge.net/).  Jalopy is a `a source code ;; formatter 
for the Sun Java programming language. It layouts any valid Java ;; source code 
according to some widely configurable rules; to meet a certain ;; coding style without 
putting a formatting burden on individual developers.'

;; Installation:
;;
;;  1) Download and install the Jalopy console plug-in package from: ;;  
http://jalopy.sourceforge.net/download.html
;;
;;  2) Put this file on your Emacs-Lisp load path and add the following into ;;  your 
.emacs startup file ;;
;;  (require 'jde-jalopy)
;;
;;  3) Customize the variable `jde-jalopy-option-path' to point to the Jalopy ;;  
installation directory. ;; ;;  4) Make sure JDE is properly configured. In particular 
set the variables ;;  jde-jdk-registry and jde-jdk so that the JVM launcher can be 
found.

;;; Usage:
;;
;;  M-x `jde-jalopy-file' to reformat the Java source file associated to the ;;  
current buffer. ;;

;;; Customization:
;;
;;  To customize the Jalopy-Emacs interface options, use the command: ;;  M-x 
`jde-jalopy-customize' 
;;
;;  The default behavior for Jalopy is to format the code according to the Sun ;;  
Code conventions. If you want to customize the formatting behavior (and ;;  Jalopy 
supports a large number of customization options), use the command: ;;  M-x 
`jde-jalopy-preferences' ;; ;;  This command will launch the Jalopy Preferences editor 
GUI-based tool. You ;;  can use it to create a file with your customized preferences. 
Point the ;;  variable `jde-jalopy-option-preferences-file' to this file. I suggest 
you ;;  save the file in the XML format, so that you can edit the preferences file ;;  
directly in an Emacs buffer later.

;;; Acknowledgements:
;;
;; This code is heavily based on jde-check.el, by Markus Mohnen.

;;; ChangeLog:
;;  1.3 - added jde-jalopy-buffer, which jalopifies a buffer in place ;; ;;  1.2 - 
jde-jalopy-buffer renamed to jde-jalopy-file to clarify its behavior. ;; ;;  1.1 - 
updates to support Jalopy 1.0b10 (changes in location of jar files) ;; ;;  1.0 - first 
version, supporting Jalopy 1.0b8

;;; Code:

(require 'jde-compile)

(if (fboundp 'jde-build-classpath)
nil
  (require 'jde-run)
  (defalias 'jde-build-classpath 'jde-run-build-classpath-arg)
  )

(defconst jde-jalopy-version "1.0b10")

(defgroup jde-jalopy nil
  "JDE Jalopy Options"
  :group 'jde
  :prefix "jde-jalopy-option-")

(defcustom jde-jalopy-option-class "de.hunsicker.jalopy.plugin.console.ConsolePlugin"
  "*Jalopy console plug-in class.  Specifies the Jalopy console plug-in class. There 
is typically no need to change this variable."
  :group 'jde-jalopy
  :type 'string)

(defcustom jde-jalopy-option-preferences-class 
  &qu

RE: Refactoring with JDE?

[Nascif Abousalh-Neto]

Hi Andrew,

> -Original Message-
> From: Andrew Hyatt [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2003 5:00 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Refactoring with JDE?
> 
> 
> "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> writes:
> 
> > Hi Andrew,
> >
> > Hmm, I have to disagree here. First I don't think you can beat a
> > refactoring editor in terms of speed if you take into account 
> > propagating the changes to
> > all affected modules, specially in a medium-large project 
> (think rename
> > method, or even rename variable for a protected variable
> used by many
> > subclasses). Since emacs is all about speed, it makes sense to use a 
> > specialized tool rather than macros and other tricks if one is 
> > available.
> 
> For things that need to know caller locations, true.  But
> jde-xref already handles that info, it could be extended to 
> some of those refactorings.  But many of the common 

Good point. What do you think should be the way to go with support for 
refactorings in JDE? I can see three major directions:
1) Expanding on the jde-xref functionality
2) Using the new semantic 2.0 - assuming it has all the necessary
functionality
3) Use a Java-based backend or C-based, like Transmogrify or xrefactory.

I think that using an approach similar to the JDE compile server, which
keeps 
an instance of the java compiler running at all times, the Java approach may
be 
feasible in terms of performance. Then again I don't know how Lisp-based
grammars
compare in terms of speed and memory usage with Java-based ones.

> refactorings such as "extract method", "pull up method", etc, 
> are easy to do by hand.  

For the "extract method" refactoring, consider a block of code 
that uses local variables. You have to create for each instance 
of a local variable an equivalent method parameter, and fill the 
method call with the associated arguments. And so on. A true 
refactoring tool is very much like a calculator; sure you can make 
basic calculations by hand and most of the time it is faster this 
way, but besides the trivial cases you always use the calculator not 
only for speed, but also so that you don't worry if any of the 
intermediate steps in your 5-digit multiplication was wrong and 
can "trust" the result - OK, maybe I am bad in math... :-)

> The problem with the more advanced IDE's is that they are
> SLOW. Eclipse is supposed to me much faster then JBuilder, 
> and Eclipse is just a dog compared to emacs.  Eclipse makes 
> doing advanced things easy, and by doing this they slow down 
> normal editing.  Personally, I prefer a fast editor above all 
> else.  (Yes, I know you can turn off certain features in 
> Eclipse to speed things up, but this eliminates many of the 
> good features of Eclipse).
> 
> Perhaps there is a way for us to have our cake and eat it
> too.  But I for one haven't thought of how.

Agreed. I also choose speed over bells and whistles hands down. 
But given Emacs power I think it may be possible to have both; 
it may be more a matter of finding the right balance between 
speed and functionality.

Regards,
/Nascif

> >
> > I have been thinking about it as well. I agree it would
> require a lot
> > of JDE changes to make things more consistent, but is that
> necessarily
> > a bad thing?
> > I don't see why JDE would lose flexibility, and actually I think it 
> > would have two benefits:
> > 1) It could make JDE more efficient by doing a very core 
> thing - keeping
> > the
> > structure of the code in a "usable" format - in exactly one place. 
> > Granted it is a complex and expensive operatation, which is exactly 
> > why it should be
> > done once and re-used by all other modules.
> > 2) It would allow for more powerful extensions/plug-ins 
> because the hard
> > work of gathering semantic info from the code would already
> have been
> > done;
> > designers would only have to learn the API to get them;
> > 3) Not only refactorings could be done but all kinds of 
> operations can
> > benefit from a better model of the code. For example, the try-catch 
> > replacement we have talked about in this list could wrap
> the code using
> > the
> > exact exceptions; searches could filter on exact
> characteristics (like
> > search method call); and so on.
> 
> It's not the flexibility of JDE I am concerned about, it's
> the flexibility of users.  It somehow feels wrong if JDE 
> would require a lock-in in the same way Eclipse (and probably 
> other JDE's do).  I agree with you to an extent about the 
> usefulness of centralizing semantic info, but I'm not sure it 
> should be done ahead of time.  If it could be done as needed 
> it might be better.
> 
> >
> > Regards,
> > /Nascif
> >
> 
> 

RE: [ANNOUNCEMENT] JDEE 2.3.3beta2

[Nascif Abousalh-Neto]

Does this version adds support for the new plug-in framework? I found no
mention of it in the release notes.
Regards,
/Nascif

FYI: CheckStyle v3.0 available

[Nascif Abousalh-Neto]

Hi, 
Looks like there is a new version of CheckStyle out there, with some really
cool enhacements (I particular I like this one: "Detect hiding of fields by
parameters or local variables with the same name").

The bad news is:
"As of release 3.0 Checkstyle has changed it's configuration system. The
configuration file is now an XML file that configures a tree of check
modules. The Checkstyle 2 configuration files (based on properties) are not
supported in Checkstyle 3. Please consult the documentation to learn about
the new configuration file format."

http://checkstyle.sourceforge.net/releasenotes.html

Regards,
  Nascif

RE: [ANN] PMD interface for Emacs

[Nascif Abousalh-Neto]

I saw your version, Jason. The current version is very similar (user the
compilation mode as well). 
Take a look at the new command, pmd-current-dir. You may want to call it
every now and then instead of calling pmd-current-buffer for every file
every time you save them (although I agree, the JVM delay is not that bad).

Actually there is quite a lot of commonality between this module, and
jde-checkstyle, and jde-jalopy, etc. Calling a Java app that redirects its
output to a compilation buffer seems to be a common pattern. It would be
good to refactor the common code into JDE. 

I'm planning to release a more efficient version (using bsh, maybe
jde-sourcepath) as soon as the next JDEE version is out with the first
version of the plug-in capability.

Regards,
Nascif

> -Original Message-
> From: Jason Rumney [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 25, 2003 5:01 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ANN] PMD interface for Emacs
> 
> 
> "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> writes:
> 
> > The emacs interface package is (so far) *not* JDEE-aware.
> 
> I've been meaning to do something with it for a few weeks 
> now. I sent in some patches a month or so ago to make it use 
> compile-mode, so at least you could click on the lines, 
> without realizing there was an improved version in CVS 
> already (so now there are two interfaces to choose from). But 
> I also planned to modify it to use bsh if available rather 
> than spawning a new JVM every time.
> 
> I run pmd as part of my write-file-hooks, and even spawning a 
> new JVM every time it has not been sufficiently slow to annoy me yet.
> 
> 
> 

[ANN] PMD interface for Emacs

[Nascif Abousalh-Neto]

Hi all,
Take a look at PMD (http://pmd.sourceforge.net/
 ). This  is a Java source code analyser
similar in some aspects to CheckStyle, but with some very interesting
non-overlapping features:

Unused local variables
Unused parameters
Empty 'if' statements
Unused private methods
Classes which could be Singletons
Classes with high Cyclomatic Complexity numbers
Classes with high coupling/high external dependencies

(OK, so CheckStyle may also support some of those, not really sure).  PMD is
also very extensible so you can create your own code checking rules.

The emacs interface package is (so far) *not* JDEE-aware.

Regards,
Nascif

RE: JDEE plugins (was JUCI)

[Nascif Abousalh-Neto]

Hi Nick,

> Where possible, talk in terms of emacs 
> interface objects (buffers, windows, frames, region, point, 
> etc.) but also express them in terms of what a Java interface 
> might look like.  What are the logical groupings for 
> retrieving certain kinds of information?  What would you name 
> an interface for fetching the current buffer, the current 
> buffer file, the current class, etc.?

I attached the module that implements the generic Java->Emacs interface in
the jde-transmogrify package. It was done to mirror the Transmogrify Hook
interface, which I believe was derived from the JBuilder plug-in interface.
We could use it as a starting point, as it is part of a working "plug-in"
(in the sense of a Java-based add-on to JDEE). 

The relevant methods (that Java code can use to change the Emacs
environment) are:

   42:  public void showReferencesSourced(IDefinition definition) {
   57:  public void showReferencesNonsourced(IDefinition definition) {
   67:  public void openFile(String sourceFileName)
   78:  public File[] getFiles()
   90:  public String getCurrentFile()
  102:  public String getUserInput(String prompt, String title)
  108:  public void displayMessage(String title, String message)
  113:  public void displayException(Exception e, String description) {
  135:  public String getText()
  146:  public String getLine(int lineNumber) 
  159:  public void selectText(int startLineNumber, 
  177:  public void selectText(int startPos, int endPos)
  188:  public void deSelectText()
  198:  public String getSelectedText()
  208:  public Enumeration getSelectedLines()
  219:  public int getCaretLineNumber()
  230:  public int getCaretOffset()
  242:  public int getCaretPos()
  248:  public int getSelectionStart() 
  254:  public int getSelectionEnd() 
  266:  public void setCaretPos(int lineNumber, int offset)
  279:  public void setCaretPos(int pos) 


Regards,
  Nascif




EmacsHook.java
Description: Binary data

RE: JDEE plugins (was JUCI)

[Nascif Abousalh-Neto]

Well, looks like I jumped the gun. There is not API to look at yet for this
JSR 198.

I suggest we just move ahead (who know long it will take to get to a point
where actual APIs are defined, this looks like a very hot politic issue as
well http://news.com.com/2100-1001-978445.html) and later consider a move to
conform to whatever they define. In the mean time we will learn a lot :-)


> -Original Message-
> From: James Higginbotham [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 19, 2003 12:21 PM
> To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; 
> Paul Kinnucan
> Cc: [EMAIL PROTECTED]
> Subject: RE: JDEE plugins (was JUCI)
> 
> 
> 
> 
> > Until
> > recently I think Emacs has been unsurpassed as the editor to 
> > use for Java, but I think some of the IDE's are catching up, 
> > specifically IntelliJ which most people I work with use.  
> > There are a few features there which I think would be easy to 
> > implement as JDE plugins (especially using reflection) but as 
> > Nascif says, I have neither the time or desire to brush up my 
> > lisp skills to do so.  If it were possible to create some 
> > basic interfaces that pure Java plugins could write to I 
> > think that would go a long way towards keeping us able to 
> > taunt other users with our editor. :)
> 
> I echo that remark.. I've been using JDE for several years 
> and I have always been able to defend it vs. things like 
> JBuilder, Visual Café, and to some extent, VAJ. But now, 
> Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs 
> and think its editor is far superior to all the rest. And 
> until now, I've always selected Emacs + JDE over anything 
> these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, 
> it seems JDE has reached the end of its extensibility until 
> this plugin design is factored in. So, now that the plugin 
> arch is being acknowledged as a must for JDE to grow as fast 
> as the current IDEs, I have to ask:
> 
> 1) What are the biggest hurdles to get JDE using this new 
> plugin arch - people, time, technology?
> 2) Is going JDE, versus integrating the Emacs editor into 
> today's IDEs, the right way to solve this problem (i.e. which 
> is more work - redesigning JDE or bridging a native editor 
> into today's popular IDEs to gain their infrastructure and 
> Emacs's editing capabilities)?
> 3) Should JDE be examining and/or joining JSR-198 to see if 
> we should be following this plugin API now, such that JDE 
> will be compliant in the future? Thus, the JDE plugin code 
> won't have to change again in a few months to allow JDE to 
> take advantage of upcoming JSR198-compliant plugins?
> 
> Just throwing out some comments to get the ball rolling. It 
> seems everyone is up for this idea, so my hope is to get us 
> thinking in the proper frame of mind, as this plugin 
> architecture may require enough redesign to rethink the way 
> JDE works now. I'm obviously not a JDE team member, nor have 
> I done much LISP, so some or all of my assumptions could be 
> slightly-to-way off. All I know is that these current IDEs 
> are giving JDE a run mostly because its written in the same 
> language as the programmer uses, reducing the barrier to 
> entry for extending it. This plugin idea is like the right 
> thing to do (and not doing it would jeopardize JDE's 
> effectiveness IMO), but I want to make sure that JDE is still 
> focusing on the right approach, not just taking the approach 
> because that's the way its been done in the past. 
> 
> Best Regards,
> James
> 

RE: JDEE plugins (was JUCI)

[Nascif Abousalh-Neto]

Hi James,
Thanks for your e-mail, and agreed in all points. I didn't realize
that there is a JSR going on for plug-ins, it is really a good idea to take
a look at it and try to conform. Once I thought about peeking one of the
more mature plug-in APIs like OpenTools for JBuilder and try to emulate, so
that we could re-use their already made plug-ins. But that are problems with
that - you're now tied to a commercial API - so a JSR-compliant API makes
much more sense.

As for your questions:

1) I would say people and technology are the major problems (we don't have a
deadline). From my little experience in this area, anything other than very
trivial plug-ins (basically launching a Java app to process the current
buffer and capture the results) requires a fair amount of elisp knowledge.
And as far as technology, as we discussed before in this list, it is quite
hard to get the Java code to drive the control flow (allowing it to change
the contents of the buffer, change the cursor position, open new windows,
etc.). It can be done but it depends on interprocess communications, which
adds a lot of complexity. I used gnuclient for that purposes, Paul used
direct socket communication in the JDEbug. The JUCI package will I believe
address this problem in a generic way.

2) I think extending JDE is the way to go. Note that it is quite easy,
today, to integrate Emacs in many IDEs by using gnuclient. 

3) As I said above, this looks like a great idea. It may be the case that we
won't be able for performance or other reasons to have a 100% Pure Java
plug-in API; but if we can, by all means it should follow a standard.

Regards,
Nascif

> -Original Message-
> From: James Higginbotham [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 19, 2003 12:21 PM
> To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; 
> Paul Kinnucan
> Cc: [EMAIL PROTECTED]
> Subject: RE: JDEE plugins (was JUCI)
> 
> 
> 
> 
> > Until
> > recently I think Emacs has been unsurpassed as the editor to 
> > use for Java, but I think some of the IDE's are catching up, 
> > specifically IntelliJ which most people I work with use.  
> > There are a few features there which I think would be easy to 
> > implement as JDE plugins (especially using reflection) but as 
> > Nascif says, I have neither the time or desire to brush up my 
> > lisp skills to do so.  If it were possible to create some 
> > basic interfaces that pure Java plugins could write to I 
> > think that would go a long way towards keeping us able to 
> > taunt other users with our editor. :)
> 
> I echo that remark.. I've been using JDE for several years 
> and I have always been able to defend it vs. things like 
> JBuilder, Visual Café, and to some extent, VAJ. But now, 
> Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs 
> and think its editor is far superior to all the rest. And 
> until now, I've always selected Emacs + JDE over anything 
> these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, 
> it seems JDE has reached the end of its extensibility until 
> this plugin design is factored in. So, now that the plugin 
> arch is being acknowledged as a must for JDE to grow as fast 
> as the current IDEs, I have to ask:
> 
> 1) What are the biggest hurdles to get JDE using this new 
> plugin arch - people, time, technology?
> 2) Is going JDE, versus integrating the Emacs editor into 
> today's IDEs, the right way to solve this problem (i.e. which 
> is more work - redesigning JDE or bridging a native editor 
> into today's popular IDEs to gain their infrastructure and 
> Emacs's editing capabilities)?
> 3) Should JDE be examining and/or joining JSR-198 to see if 
> we should be following this plugin API now, such that JDE 
> will be compliant in the future? Thus, the JDE plugin code 
> won't have to change again in a few months to allow JDE to 
> take advantage of upcoming JSR198-compliant plugins?
> 
> Just throwing out some comments to get the ball rolling. It 
> seems everyone is up for this idea, so my hope is to get us 
> thinking in the proper frame of mind, as this plugin 
> architecture may require enough redesign to rethink the way 
> JDE works now. I'm obviously not a JDE team member, nor have 
> I done much LISP, so some or all of my assumptions could be 
> slightly-to-way off. All I know is that these current IDEs 
> are giving JDE a run mostly because its written in the same 
> language as the programmer uses, reducing the barrier to 
> entry for extending it. This plugin idea is like the right 
> thing to do (and not doing it would jeopardize JDE's 
> effectiveness IMO), but I want to make sure that JDE is still 
> focusing on the right approach, not just taking the approach 
> because that's the way its been done in the past. 
> 
> Best Regards,
> James
> 

RE: JDEE plugins (was JUCI)

[Nascif Abousalh-Neto]

Hi Paul,

Just to recap:
1) The plug-in will follow the proposed directory structure;
2) It will have a lisp/plugin.el file that will be evaluated at load time by
JDE (still not sure what goes here, any suggestion?);
3) It can assume that its libraries will be in the BeanShell classpath;
4) Based on (3), it can replace direct invocations of the JVM with jde-eval
calls (which should make it much faster)

Problem with (4) is how to get the output to a compilation buffer. When I
launch a new JVM process myself, I can just redirect the output to any
buffer I choose; if I launch the Java portion of the plug-in from the
BeanShell, the output goes to stdout, which is captured as lisp forms by the
BeanShell, right? Sorry if that is a basic elisp question, but how do I
redirect that output to a compilation buffer? I guess I could use that code
you mentioned. I looked at the code at jde-checkstyle.el for an example but
my impression is that it launches an new JVM for each invocation instead of
using the BeanShell, is that correct? As a first pass it should be OK for
the plugin to do the same, but then we will be missing an opportunity for
code re-use.

I agree with the others that the less elisp requirements we have the larger
will be the pool of plug-in contributors; I believe JUCI will be able to
help us with this part; maybe some elisp code generation facility based on
Java Reflection or config files could also complement it. 

I think the final design goals should be:
1) "Drop-in" install; just adding a jar or zip file to a specific directory
would be sufficient to install the package and integrate it with JDEE menus;
1.1) With a plug-in manager menu to enable/disable plug-ins;
2) Minimal to none elisp code required. I think we will have elisp-based
plug-ins as well, but I expect most to be Java-based - just because most
JDEE users know Java much better than they know Lisp.

What would be the list of "resources" available to the Java code in the
plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point
position, region content, files in sourcepath, etc. easily available? Maybe
a basic class that they could extend? We have to define the container
environment for the plug-ins.

Finally, how do we manage different versions of common Java libraries (like
XML parsers) among plug-ins?

Regards,
  Nascif





> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, February 18, 2003 5:25 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]
> Cc: Paul Kinnucan; [EMAIL PROTECTED]
> Subject: RE: JDEE plugins (was JUCI)
> 
> 
> Nascif Abousalh-Neto writes:
>  > Sounds like a great idea!
>  > 
>  > I would volunteer to re-write the Jalopy 
> (http://jalopy.sourceforge.net/)  > integration package I put 
> together. I could also take a stab at a re-write  > for the 
> integration package for PMD (http://pmd.sourceforge.net/).  > 
>  > Those Elisp->Java packages have an awful lot of code in 
> common, and it would  > be really nice to create a standard 
> way to create them - specially the bit  > about a standard 
> way to integrate with the BeanShell.  > 
> 
> Great. I assume that you will conform to the directory 
> structure that I proposed and provide the package as a jar or 
> lisp file. Please let me know if you intend to implement any 
> other suggestions, e.g., Ole's idea of a standard entry 
> point: lisp/plugin.el
> 
>  > I would like to suggest also a standard way for those 
> packages to present  > their output. A lot of them generate 
> warnings or errors that go very well in  > a "compilation" 
> mode buffer. I think this behavior can be abstracted as  > well.  > 
> 
> beanshell.el previously contained an unfinished eieio class 
> that provides a compilation-style buffer for BeanShell-based 
> applications. My idea is that the compile server and the ant 
> package and any other Beanshell based applications that 
> needed compilation-like buffers could specialize and 
> instantiate this class. I deleted it in my last update but I 
> think I'll revive it.
> 
> - Paul
> 
>  > Regards,
>  >   Nascif
>  > 
>  > 
>  > 
>  > > -Original Message-
>  > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] 
>  > > Sent: Tuesday, February 18, 2003 3:27 PM
>  > > To: [EMAIL PROTECTED]
>  > > Subject: JDEE plugins (was JUCI)
>  > > 
>  > > 
>  > > 
>  > > Hi Nick,
>  > > 
>  > > I am posting my response to your idea of JUCI-based 
> plugins  > >  to the JDEE list because I am interested  > > 
> in getting other people's input on this idea.  > > 
>  > > - Paul
>  > > 
>  > > 
>

RE: Java -> elisp communication (was RE: BanInfo wizard anyone?)

[Nascif Abousalh-Neto]

Title: RE: Java -> elisp communication (was RE: BanInfo wizard anyone?)





Hi Paul,
    I think that in the case of Transmogrify we didn't have much choice. We wanted to interface with an engine and an interface that was already defined, so we could not change the control flow to use queues and even handlers. Maybe an adaptation layer could do the trick, I don't know. I didn't have enough elisp knowledge to create and manipulate sockets from the lisp side, so gnuclient sounded like a good compromise.

    Do you think it would be possible to expose the mechanism you implemented for MATLAB as an open, documented, JDE extension API? It sounds like you have solved the communication portion of the problem already, while Nick's JUCI takes care of hiding the elisp learning curve from Java programmers. Combine both and you have an open plug-in interface for JDE!

    I had recently used the Java 1.4 Dynamic Proxy feature to implement proxies as well (to extend CORBA to support JAAS-based authorization). This could also be used I suppose to provide a elisp "encoding" plus dispatching for arbitrary Java interfaces.

    Regards,
        Nascif



> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, December 09, 2002 3:59 PM
> To: Nick Sieger
> Cc: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; [EMAIL PROTECTED]; 
> Graham Bennett
> Subject: RE: Java -> elisp communication (was RE: BanInfo 
> wizard anyone?)
> 
> 
> Nick Sieger writes:
>  > > From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
>  > > Sent: Monday, December 09, 2002 11:46 AM
>  > > To: Nick Sieger; Galen Boyer; [EMAIL PROTECTED]
>  > > Cc: Graham Bennett
>  > > Subject: Java -> elisp communication (was RE: BanInfo 
> wizard anyone?)  > > 
>  
> 
> [snip]
> 
>  > > 3) Both my implementation and Graham's use gnuclient to 
>  > > implement the Java -> elisp side of the equation (elisp -> 
>  > > Java using the BeanShell support in JDE). The reason being 
>  > > that Java tools will need (and that is true for Transmogrify) 
>  > > to make asynchronous calls to the elisp side.
> 
> gnuclient is not necessary to do this. My interface between 
> the MATLAB debugger and Emacs, implemented in Java (one of 
> MATLAB's extension languages), uses threads and sockets to 
> handle asynchronous communications (i.e., debugger events) 
> between the debugger and Emacs. At startup, the MATLAB-Emacs 
> interface creates an Emacs-Matlab communictions socket and 
> starts a "transciever" thread to listen for input on the 
> socket. The interface then starts Emacs, using a command-line 
> switch that starts up the Emacs side of the MATLAB-Emacs 
> interface. The Emacs side of the interface creates a process 
> that listens for input from the socket created by the MATLAB 
> side. The input is always in the form of a Lisp form that the 
> Emacs "transceiver" evaluates.  The MATLAB side of the 
> interface listens for debugger events (e.g., a breakpoint 
> hit) and reformats them as Lisp function evaluations (e.g., 
> (matlab-eei-breakpoint-hit "matlab-function.m" 22)) that are 
> evaluated by the Emacs side. 
> In other words, the Emacs side of the interface has a whole 
> bunch of functions that correspond to debugger events. The 
> Java side of the interface invokes them to do things like 
> move a debug cursor through code being displayed in an Emacs buffer.
> 
> In general, I highly recommend that anyone trying to 
> implement an interface between Emacs and an external 
> application do so via an asynchronous interface, i.e., each 
> side interacts with the other side purely via commands and 
> event handlers, e.g., if Emacs needs a response to a command 
> sent to the other side, it should register an event handler 
> for the response, issue the external command, and return to 
> the internal (Emacs user) command loop. It should not attempt 
> to suspend Emacs until the response comes back. If Emacs 
> needs to issue a sequence of commands to the other side, with 
> each command completing before the next is issued, it can 
> create a queue of commands and have the event handler for the 
> previous command issue the next command in the sequence. This 
> approach is far more robust in my experience than having each 
> command suspend Emacs until the other side responds to the command.
> 
> - Paul
> 
>  
>  > > I'm curious on how the JUCI would solve that problem, as I 
>  > > assume the BeanShell call that starts the communication with 
>  > > the Java portion would block until a response is received, so 
>  > > how c

Java -> elisp communication (was RE: BanInfo wizard anyone?)

[Nascif Abousalh-Neto]

Title: Java -> elisp communication (was RE: BanInfo wizard anyone?)





Hi Nick,


> > >> The translation layer could handle things like the java method 
> > >> signature returning, say, a hashmap.  The layer could have a 
> > >> hashmap to alist converter.
> > > 
> > > I've actually got a working prototype of a generic 
> > > interface/translation layer that does just that.  For now, I'm 
> > > calling it JUCI (JDEE Universal Communication Interface). 
>  It allows 
> > > elisp to call java and java to call back to elisp in a standard 
> > > manner.  It's still very alpha.  One (minor, IMHO) 
> drawback is that 
> > > it requires JDK 1.3 or greater, because I'm making use of the 
> > > java.lang.reflect.Proxy mechanism.
> [..elided...]
> > 
> > I see.  You aren't referencing the beanshell here.  Are you 
> opening up 
> > a direct connection to a JVM?
> 
> Well, I didn't, but the beanshell is still directly involved. 
>  Elisp sends strings to the beanshell which invokes java 
> code, and java code invokes interfaces which, through a 
> proxy, print lisp forms back to stdout and are evaluated by 
> `bsh-eval-r'.


I looked into this problem some time ago, and actually got a working interface between Transmogrify and Emacs, using their Hook interface. You can download it from http://home.nc.rr.com/nascifandelaine/emacs.html. 

Some comments though:
1) Development in Transmogrify has not being very active for quite some time (http://sourceforge.net/mailarchive/forum.php?thread_id=612615&forum_id=1015). The last major release is more than a year and a half old and I don't see any signs of a new release soon.

2) Graham Bennet has an implementation of a Refactoring tool for Java already integrated with Emacs. His tool takes some pages from Transmogrify http://freefactor.sourceforge.net.

3) Both my implementation and Graham's use gnuclient to implement the Java -> elisp side of the equation (elisp -> Java using the BeanShell support in JDE). The reason being that Java tools will need (and that is true for Transmogrify) to make asynchronous calls to the elisp side. 

I'm curious on how the JUCI would solve that problem, as I assume the BeanShell call that starts the communication with the Java portion would block until a response is received, so how could the Java portion (in the same thread of execution) submit a lisp form back for evaluation? Would you use multiple BeanShell instances or multiple threads inside Beanshell, one to submit the Java request and one to "listen" to stdout for asynchronous evaluation requests?

An "real world" example from my Transmogrify Hook implementation should make it clear. Let's say you use the elisp interface to call the ExtractMethod refactoring on Transmogrify. The steps would be:

1) User marks a region in the current buffer and calls "jde-transmogrify-extract-method";
2) This defun calls jde-eval, using the BeanShell to activate the Transmogrify engine;
3) Transmogrify gathers the necessary information by making calls to the Hook interface:


Here I'm guessing a little, I don't remember exactly the number and order of calls to the Hook interface.
For simplicity let's assume all the source code info can be obtained in 3.2 call. It could actually require three to four calls to obtain line number, caret position, etc.

3.1) getUserInput (to obtain the new method name)
3.2) getSelecteText (to obtain the body of the extracted method)
3.3) displayMessage or displayException (for the result)


Each one of the 3.* calls will create an elisp form that will be sent (via gnuclient) back to Emacs for evaluation.
The processing keeps going back and forth between the Transmogrify engine and Emacs (through the hook implementation and gnuclient) until Transmogrify has all the info it needs, at which point:

4) Transmogrify applies the refactoring to the source code;
5) Transmogrify returns the control to the original jde-eval call.
6) jde-transmogrify-extract-method completes


(this is really asking for an UML sequence diagram :-)


So even though the refactoring is "put in motion" by the jde-eval call, the control of execution is pretty much in the hands of Transmogrify. Emacs must be ready to act as an "evaluation server", receiving forms on demand. This is the behavior implemented by gnuserv/gnuclient. It would be great if you can find a way to implement this behavior using BeanShell only. You mentioned that the Java code would print "lisp forms back to stdout and are evaluated by `bsh-eval-r'". Doesn't that imply that you are limited to control flows where Emacs is driving? How can the Java proxy "trigger" the call to bsh-eval-r, get the result of the evaluation and recover the control of the execution flow - for example, to move from 3.1 to 3.2 in the scenario described above?

All that said I would love to see something like JUCI actually integrated into JDE; I advocated that in many messages some months ago. I just don't see how the requirements of generic Java tools (like asyn

RE: jde-jalopy.el

[Nascif Abousalh-Neto]

Title: RE: jde-jalopy.el





http://home.nc.rr.com/nascifandelaine/emacs.html


Enjoy,
  Nascif


> -Original Message-
> From: Keith Kee [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, December 04, 2002 12:20 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: jde-jalopy.el
> 
> 
> Hi:
>   Where do I pick up the latest jde-jalopy.el?
> 
> Thanks
> keith
> 

Refactoring Wish List

[Nascif Abousalh-Neto]

Title: Refactoring Wish List





So far we have:


1. Changing class name (and all references).
2. Changing names of any choosen class member - field, method (and all references)
3. Changing package for one or more classes with 'one click' (and all references)
4. Moving class to different package
5. Create factory method in place of constructor
6. Extract method from selected piece of code
7. Extract super class or interface for selected piece of code and set of fields
8. Deleting classes/methods/attributes 
9. Copying classes into other packages
10.Copying methods/attributes into other classes


I would like to see some features from Transmogrify, which may not be necessarily refactorings but are easy to implement once you have a refactoring framework (which requires the complete syntax trees plus reference resolution) in place:

11. Wrapping a block of code in a try/catch (exceptions needed extracted from the signatures of the methods in the block)

12. Finding out unsused variables/methods/classes
13. Finding out shadowed variables/methods


Maybe we should have a page somewhere and vote? A system like bugzilla to track requirements/bugs and get user input on the most desirable ones would be nice.

For a comprehensive list of Refactorings as documented by Martin Fowler, check http://www.refactoring.com/catalog/index.html

Regards,
    Nascif

RE: prj.el under source control

[Nascif Abousalh-Neto]

Title: Message



Hi 
Guillaume, 
  That is a very good hint, I'll keep an eye for 
that.
 
Thanks,
    Nascif

  
  -Original Message-From: Guillaume Berche 
  [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 
  2002 3:14 AMTo: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; 
  [EMAIL PROTECTED]Subject: RE: prj.el under source 
  control
  Nascif ,
   
  I've 
  had similar problems using CVS on a previous JDEE version. The problem was I 
  added the prj.el files as a text file whereas under certain conditions it 
  might contain binary characters (such as when specfying a control key in the 
  key bindings) that CVS considered as end-of-file marker, and thus truncated 
  the file. After modifying the file attribute to binary, this worked again. 
  
   
  I 
  hope this can help,
  Guillaume. 
  
-Original Message-From: Nascif Abousalh-Neto 
[mailto:[EMAIL PROTECTED]]Sent: mardi 19 novembre 2002 
22:29To: [EMAIL PROTECTED]Subject: prj.el under source 
control
Hi, 
    I recently added our prj.el files to source control 
(clearcase) but soon after that I start to get some strange behavior - 
basically related to loss of customizations, like modeline, font-lock, key 
bindings, and project name. I'm not sure it is related, but I'm thinking 
that the fact that fact that the prj.el is now read-only may be causing 
problems. Could that be the case?
    Another variable: I recently migrated from 
jde2.2.9beta10 to jde2.2.9. I tried to move back but the problem 
persisted.
    Regards, 
    
    Nascif 
PS: Still no comments on my 
previous question on how to have subprojects appending to paths defined on 
parent projects, instead of just overriding 
then...

RE: prj.el under source control

[Nascif Abousalh-Neto]

Title: RE: prj.el under source control





I found out the reason, somehow I lost the entire contents of my (custom-set-variables) in my .emacs !!!
I don't know what caused that though. I restored it from a backup and things seem to be back to normal now.


> -Original Message-
> From: Tom Eskridge [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, November 19, 2002 4:54 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; [EMAIL PROTECTED]
> Subject: Re: prj.el under source control
> 
> 
> 
> I have been getting the same behavior since switching to 
> 2.2.9.  It may be 
> more likely to be a jde issue than a source control issue.
> 
> On Tuesday 19 November 2002 03:28 pm, Nascif Abousalh-Neto wrote:
> > Hi,
> >     I recently added our prj.el files to source control 
> (clearcase) but 
> > soon after that I start to get some strange behavior - basically 
> > related to loss of customizations, like modeline, font-lock, key 
> > bindings, and project name. I'm not sure it is related, but I'm 
> > thinking that the fact that fact that the prj.el is now 
> read-only may 
> > be causing problems. Could that be the case?
> >     Another variable: I recently migrated from jde2.2.9beta10 to 
> > jde2.2.9. I tried to move back but the problem persisted.
> >
> >     Regards,
> >         Nascif
> >
> > PS: Still no comments on my previous question on how to have 
> > subprojects appending to paths defined on parent projects, 
> instead of 
> > just overriding then...
> 
> -- 
> 
> Cheers,
> 
> Tom
> 
> 
> Tom Eskridge
> Institute for Human and Machine Cognition
> University of West Florida
> 40 S. Alcaniz St
> Pensacola, FL 32501
> ph: 850-202-4454
> fx: 850-202-4440
> 

RE: prj.el under source control

[Nascif Abousalh-Neto]

Title: RE: prj.el under source control





Thanks, appreciated. 
Maybe a special symbol meaning the contents of the same variable as defined in a parent (or default) prj.el would do the trick... So you could have

jde-global-classpath = ($BASE_VALUE "this/project/dir")



> -Original Message-
> From: Andrew Hyatt [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, November 19, 2002 4:56 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]
> Cc: [EMAIL PROTECTED]
> Subject: Re: prj.el under source control
> 
> 
> "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> writes:
> 
> > PS: Still no comments on my previous question on how to have 
> > subprojects appending to paths defined on parent projects, 
> instead of 
> > just overriding then...
> 
> I haven't looked at the code to do this, but I imagine this 
> would be a fairly easy fix.  And I think it's a good 
> suggestion.  I'll see if I can produce a patch soon.
> 
> 

prj.el under source control

[Nascif Abousalh-Neto]

Title: prj.el under source control





Hi,
    I recently added our prj.el files to source control (clearcase) but soon after that I start to get some strange behavior - basically related to loss of customizations, like modeline, font-lock, key bindings, and project name. I'm not sure it is related, but I'm thinking that the fact that fact that the prj.el is now read-only may be causing problems. Could that be the case?

    Another variable: I recently migrated from jde2.2.9beta10 to jde2.2.9. I tried to move back but the problem persisted.

    Regards,
        Nascif


PS: Still no comments on my previous question on how to have subprojects appending to paths defined on parent projects, instead of just overriding then...

accumulative changes in prj.el files

[Nascif Abousalh-Neto]

Title: accumulative changes in prj.el files





Hi,
    I would like to setup my prj.el files so that I can have the subproject prj.el files adding to basic values defined on the master prj.el, or on my .emacs.

    For example, I would like to have a basic lists of classes defined for the jde-global-classpath and jde-sourcepath lists, and have prj.el on subprojects adding classes to those lists - not completely redefining them.

    I guess I could do that writing elisp code in my prj.el file, but I remember reading somewhere that you are not supposed to direct set the values of "defcustom" variables. So I would like to keep using the custom package to manipulate those variables if at all possible.

    I would appreciate any help.


    Regards,
        Nascif

RE: Re[4]: missing features in jde?

[Nascif Abousalh-Neto]

Title: RE: Re[4]: missing features in jde?





Hi there,
    The problem of usage information gathering is also a pre-requisite to the implementation of refactoring tools (and xref is actually an example of such a tool). So they provide a good place to look for examples on how to solve this problem (as long as you don't mind using Java instead of elisp for the parsing engine).

    Below you will find links to open source refactoring tools for Java . FreeFactor has already an Emacs interface.

https://sourceforge.net/projects/freefactor/
https://sourceforge.net/projects/transmogrify/
http://jrefactory.sourceforge.net/csr-commandline.html


    Good luck,
        Nascif



> -Original Message-
> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, October 25, 2002 2:30 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re[4]: missing features in jde?
> 
> 
> Semanticdb for the next release is much more advanced than 
> the current one.  It will come with a command line program to 
> build a complete set of databases you can reference.
> 
> It still won't help with usage information though.
> 
> Eric
> 
> >>> Andrew Hyatt <[EMAIL PROTECTED]> seems to think that:
> >
> >So far I haven't found a way to get the information I need 
> by Semantic 
> >only.  I think actually it is theoretically impossible, 
> unless we also 
> >require semanticdb's to be made for each file.  We could do 
> it with a 
> >combination of Semantic and bsh, but that sort of thing has 
> been slow 
> >for me in the past (when we use completion, for instance), 
> so I'm not 
> >too confident about it.
> >
> >I think a better way to do it is to parse the class file 
> itself.  The 
> >Java compiler has already done the heavy lifting here, it 
> has the exact 
> >fully-qualified functions that are called, we just need to 
> go and parse 
> >out the relevant information.  I think this could be very 
> fast.  Also, 
> >this allows us to retrieve usage information for anything 
> that compiles 
> >to Java bytecode, and gives us access to classes we don't have the 
> >source code to.  The disadvantage if we don't get line 
> numbers if the 
> >class file has no debug info, but we could get the class and 
> function 
> >name each call is in.  I think that's good enough.
> >
> >I'm working on the class-file based approach right now, and 
> am building 
> >a simple parser for it (I don't think semantic can handle 
> binary files, 
> >but correct me if I'm wrong).  Whether I do a full parser of just a 
> >quick parse of the stuff we need I haven't decided yet.
> >
> >
> >
> >"Eric M. Ludlam" <[EMAIL PROTECTED]> writes:
> >
> >> It might be possible to do such a thing with semantic 1.4, 
> though it 
> >> would be very slow. The new bison based parser David Ponce ported 
> >> into the semantic 2.0 CVS also has a full java parser.  I'm not 
> >> exactly sure what it's capabilities are though.  As far as I know, 
> >> the CVS version is still compatible with the current 
> version of JDE.
> >> 
> >> Eric
> >> 
> >> >>> Andrew Hyatt <[EMAIL PROTECTED]> seems to think that:
> >> >
> >> >You can actually get the "find usages" functionality with 
> the xref 
> >> >program, a program not only amazing for this feature, but 
> also the 
> >> >fact that it is an emacs extension that costs money!
> >> >
> >> >See it at:
> >> >http://xref-tech.com/xrefactory/
> >> >
> >> >It costs $29.  I bought it and use it, and it's good, but 
> I think a 
> >> >better solution could probably be designed for free.
> >> >
> >> >I'd actually like to work on this functionality for jde, 
> if it was 
> >> >possible to do.  I don't know enough about semantic to 
> tell whether 
> >> >it is powerful enough to support this functionality (all we would 
> >> >need is to tag lines by what functions of what classes 
> are called, 
> >> >then create and store a big table of these), but I think 
> so.  We can 
> >> >take it a step farther than xref by adding functionality 
> to produce 
> >> >call trees, which would be incredibly useful.
> >> >
> >> >Even though it appears possible, I remember reading on this list 
> >> >that it would require semantic 2.0 to do?  If anyone has 
> any further 
> >> >information on that, I'd be interested to hear.
> >> >
> >> >
> >> >
> >> >Paul Kinnucan <[EMAIL PROTECTED]> writes:
> >> >
> >> >> Raul Acevedo writes:
> >> >>  > I've been using JDE for a while, and while I'm 
> generally happy 
> >> >> with it,  > there is some basic functionality that it 
> seems to be 
> >> >> missing:  >  > *  Minibuffer completion on class names for 
> >> >> jde-open-class-source.  >
> >> >>  > * "Find usages" functionality: list all 
> callers/users for a given
> >> >>  >    method, field or class.  No, I don't want to use 
> grep, I want
> >> >>  >    something 100% reliable.
> >> >>  > 
> >> >>  > *  Functionality to list all classes/interfaces 
> which implement/extend a
> >> 

ECB 1.80 vs JDE 2.2.9beta10: Semantic version conflict?

[Nascif Abousalh-Neto]

Title: ECB 1.80 vs JDE 2.2.9beta10: Semantic version conflict?





Hi,
    I installed the latest ECB and required packages. One of the changes was to upgrade to the latest version of semantic, 1.4. I later found out that JDE wouldn't launch. JDE prints an error message claiming that it supports Semantic only up to the version 1.4beta14.

    I tried to force JDE by changing the version check, but then calls like jde-normalize-path started to fail.


    Regards,
        Nascif



-Original Message-
From: Jesper Nordenberg [mailto:[EMAIL PROTECTED]] 
Sent: Monday, August 12, 2002 4:13 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: ECB 1.80



ECB, Emacs Code Browser, version 1.80 is now available at:


http://home.swipnet.se/mayhem/ecb.html


This release contains many new features and some bug fixes. ECB now requires semantic 1.4 and EIEIO 0.17, no beta versions.

ECB is a source code browser that displays directories, source files, methods and variables that can be navigated using the mouse (and keyboard). It supports parsing of Java, C, C++ and Elisp source code. It is completely written in Emacs Lisp and uses semantic to parse source files.

Contributions, suggestions and bug reports are welcome!  Please send them to the public mailing list:


http://lists.sourceforge.net/lists/listinfo/ecb-list


/Jesper Nordenberg

ANN: JDE interface to Code Beautifier (Jalopy)

[Nascif Abousalh-Neto]

Title: ANN: JDE interface to Code Beautifier (Jalopy)





Hi all,
    Attached you will find an Emacs/JDEE "plug-in" package for the Jalopy tool. From the Jalopy (http://jalopy.sourceforge.net/) web page:

"Jalopy is a source code formatter for the Sun Java programming language. It layouts any valid Java source code according to some widely configurable rules; to meet a certain coding style without putting a formatting burden on individual developers.

With Jalopy you will be able to transform any foreign coding style to your own preferences, without any browbeating or bloodletting.

Jalopy's functionality covers:


Brace style transformation
Fine-grained whitespace settings
Indentation
Intelligent line wrapping
Code separation
Javadoc auto-generation
Header/Footer templates"


Paul,
    I don't have a permanent web page to store the file, so I would appreciate if you could add it to the "Contributed software" page.

Enjoy,
    Nascif


 




jde-jalopy.el
Description: Binary data

RE: Interfacing Java tools with JDEE

[Nascif Abousalh-Neto]

Title: RE: Interfacing Java tools with JDEE





Hi Vasek,


> -Original Message-
> From: Vaclav Barta [mailto:[EMAIL PROTECTED]]


> > Paul, what about people that want to write a Java plug-in for *any*
> > editor? In that sense
> It's simple: they can't. Not all Java editors are written in Java


OK, I was too generic. But you would agree that *most* of the Java
editors in large use today 1) are Java-based 2) support extensions (plug-ins)
written in Java.


> - you'll always have different languages standing in the way of re-use...
> For maximum pluggability, you can go below programming language level
> and communicate using structured data - Emacs supports that (note how
> pluggable javac and other compilers are), but of course it has its own
> problems...


I want to solve a much more specific problem: Java plug-ins for JDEE.


> > JDEE/Emacs is too far away from the other IDEs out there. Not better
> > or worse, but different.
> It isn't just the case of Emacs - I wouldn't expect (for example)
> Microsoft tools to be scriptable in Java either...


I'm not trying to solve that problem.


[snip]


> > I think JDEE would greatly benefit by providing a true Java-based
> > plug-in architecture and removing the elisp "language 
> barrier". What is
> I disagree. IMHO it's Emacs which would greatly benefit from being
> scriptable in multiple languages - but I don't see that happening this
> century... :-)


Maybe, but I'm not fighting this battle. Last time I posted about this issue
I got a lot of replies talking about extending Emacs with Java, Perl, etc.
This is not the point I'm making. I'm talking about a very specific feature (support for Java
plug-ins) for a very specific Emacs package (JDEE).  I think that by keeping the focus
we can have it happenning much sooner than the end of the century... ;-)


> > and easy to use way for Java designers to extend JDEE? 
> Nothing against
> > learning elisp, but code re-use and standardization are worthwhile
> Well, Emacs is standartized on elisp. I agree that most Java tools are
> standartized on something entirely different, but if someting has to
> give,
> I'd try to push the Java tools first - Emacs is just too 
> heavy to push 
> around...


Emacs is flexible enough to support a middle ground solution.
Regards,
    Nascif

RE: Interfacing Java tools with JDEE

[Nascif Abousalh-Neto]

Title: RE: Interfacing Java tools with JDEE





[snip]


> The advantage of this approach is that it reduces developing
> interfaces to external Java processes to writing eieio classes.
> The interface developer doesn't have to write any Java code or
> interprocess communications.


This is a very interesting idea! It cuts directly to one of the things
that a plug-in archtecture should do: hide difficult details
from the tool writer (interprocess communication) through
code generation and code re-use.


> This doesn't really help the elisp illiterate plugin tool developer,
> but it would make it easy to create and maintain a plugin 
> interface for the JDEE.


What about doing it in the other direction: creating eieio classes
from existing Java classes? The generated eieio classes could extend basic
classes designed for easy integration into the JDEE plug-in framework.


Generating Lisp from Java seems to be more appropriate in this particular
problem, since typically the Java code will already exist (in the form of a
library or tool that we want to add to JDEE).


To create a pure Lisp plug-in, the designer would just have to extend the
plug-in eieio classes directly.


This is nice, it seems that this discussion is making some progress in terms of
a viable plug-in framework design...


Regards,
    Nascif

RE: Interfacing Java tools with JDEE

[Nascif Abousalh-Neto]

Title: RE: Interfacing Java tools with JDEE





Hi Paul,


[snip]
> The jde-jeval function already provides all the functionality required
> for two-way communication between the JDEE and an external Java
> application. I explained how this works in a previous post.


Paul,
jde-jeval provides all the functionality required for two-way communication - assuming that: 


    1) the Java tool was written with Emacs interaction in mind, since in order to do Java->elisp actions
    the tool has to return proper elisp code for evaluation.


    2) The flow control is completely under the control of the elisp side.


These two assumptions are not always the case for many good tools out there.
Nonetheless these tools are useful enough to make their integration to JDEE a worthwhile goal.


Take a refactoring tool like Transmogrify as an example. 
First, it was designed as a plug-in for a generic Java editor, and Emacs-JDEE currently don't qualify as such.
Case in point, Transmogrify don't return elisp code for evaluation to affect the environment.


Second, once a refactoring is started (in the JDEE case, by a jde-eval call to the associated Java method) 
the tool takes control of the flow control, making calls back to the editor environment based on internal 
decisions. For example, it may query the contents of the region, and based on analysis of that content ask
the editor to change point. This is a much more complex iteration model than the one supported by jde-jeval.


>  The only thing that Nascif is proposing to add is
> a Java wrapper around Lisp code required for the Java application
> to manipulate Emacs. 


From the discussion above, you can see that this wrapper is much more than that.
It allows JDEE to be extended with Java tools that know nothing about Emacs or Elisp,
and is much more flexible in its assumptions of the flow control.


> I think the jde-jeval approach of having
> the Java process simply return Lisp code is superior because it
> allows the Java process to have access to the full range of 
> Emacs functionality. 


True, but at a big price; to use this approach a Java tool has to be written (or re-written) to fit into
the jde-jeval model. I won't argue that it is better for tools created from scratch to be integrated with
Emacs by a Java/Lisp programmer; but I don't think it is sufficient to support already existing tools, 
nor tools created by designers that are not proficient in elisp.


> With Nascif's approach, only the functionality
> exposed by the wrapper code is available to the Java process. 


True, but then again, plug-ins typically are designed with access to a very small and well-defined
API to the environment (the editor) in mind. With a dozen methods exposed (get/set region,
get/set point, load buffer, etc.) we would be able to support a very broad range of Java plug-ins.


We could always expose a Lisp "pass-through", to allow the Java tool to send elisp code back.
In this way the Java wrapper would be a superset of the jde-jeval approach.


> As for avoiding learning Lisp, I think people who want to write Java
> extensions to Emacs are better off putting their effort in learning
> elisp than in learning a Java wrapper around elisp.


Paul, what about people that want to write a Java plug-in for *any* editor? In that sense
JDEE/Emacs is too far away from the other IDEs out there. Not better or worse, but different. 
True, there is no "standard" for plug-ins at this point, but the ones already available (from NetBeans, 
JEdit, JBuilder, just to name a few) don't rely on elisp... 
Not to mention the plug-ins and tools that have already been written. Is it a good position to simply 
ignore them, or to have to rewrite them from scratch?


I think JDEE would greatly benefit by providing a true Java-based plug-in architecture and
removing the elisp "language barrier". What is the problem of offering a more generic
and easy to use way for Java designers to extend JDEE? Nothing against learning elisp, 
but code re-use and standardization are worthwhile design goals as well. They may take away some flexibility,
but the payback is great - more people will be adding extensions because of the reduced barriers.


Best Regards,
    Nascif

Re: Interfacing Java tools with JDEE

[Nascif Abousalh-Neto]

Title: Re: Interfacing Java tools with JDEE





Hi Graham,


[snip]


> complicated.  The main problem is that emacs seems only to send data
> back when the socket is shutdown, so I have to continually 
> reinitialise the socket.  


I think that using sockets is better that using gnuclient, since:
 - not all designers enable or install gnuclient;
 - every operation on the Java->Emacs direction will create a new process
(gnuclient), and the overhead can add up;
 - the windows pop-ups created by gnuclient can be annoying (yes, I tried to
use gnuclientw).


Maybe once you share the socket code with this list the gurus could help you work out the problems :-)


> The main problem is communicating in the other direction, for example
> when the user selects a menu option. 


As you mentioned in your other e-mail, using the Beanshel-based jde-eval is probably the way to go here.


[snip]


> therefore hack up the elisp end of it as well.  There's no reason that
> the resulting elisp/java couldn't be made a bit more abstract so it
> would be useful to other people.


I think that a generic JDE interface for Java extensions would have the following elements:
 - A Java API to encapsulate the Java->Emacs communications (with methods like move point, change selection, get region, etc.) This code would do the socket-based or gnuclient-based communication behind the scenes.

 - An "installer" tool that would generate the necessary elisp wrapper code from a Java  interface. I think that using Java Reflection this would be an easy task,

although another option would be to require the tool writer to provide an "interface descriptor" in a text or XML file - which could support annotations for the creation of menus and keybinds.

The first component would be used by the most complex "full-duplex" tools, like refactoring libraries and UML browsers (for example, to allow changes in an UML GUI to be reflected in an Emacs buffer).

The second could be used by both full-duplex and the most generic half-duplex tools, where elisp is used to call a Java library for a straightforward operation - like the JDE wizards, code checkers and beautifiers, etc.

With these two components Java designers would have a much easier time extending JDEE - all the hard work, including writing the elisp wrappers and the communication code, would have already been done for them, and in an standard way.

Regards,
    Nascif

RE: OT Learning Lisp

[Nascif Abousalh-Neto]

Title: RE: OT Learning Lisp





Hi Kevin,
    Check out the GNU Emacs Lisp Intro. There are many versions around, check this one at: http://www.gnu.org/manual/emacs-lisp-intro/html_mono/emacs-lisp-intro.html

    Regards,
        Nascif



> -Original Message-
> From: Kevin Jones [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 9:42 AM
> To: Jde
> Subject: OT Learning Lisp
> 
> 
> I often come across features in JDE (and other Emacs libs) 
> that I'd like
> to work on but my Lisp knowledge is minimal (at best). I have the
> Writing Emacs Extensions book, but I'm looking for a better 
> introduction
> to lisp programming, preferably but not necessarily, with an Emacs
> slant. Any recommendations would be gratefully received.
> 
> Oh and sorry for the OT post, I couldn't think of a better 
> group to ask
> :-)
> 
> Kevin Jones
> Developmentor
> www.develop.com
> 
> 

RE: Extending JDE using Java (WAS: Gosling interview)

[Nascif Abousalh-Neto]

Title: RE: Extending JDE using Java (WAS: Gosling interview)





> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Matt Munz writes:
>  > Nascif,
>  > 
>  > I have been curious about the BeanShell since I heard 
> about it, but haven't
>  > tried it yet. It sounds like you're familiar with it.
>  > 
>  > Nacif> It is easy to have a Lisp function calling a Java 
> method, using the
>  > BeanShell; not so much to do the reverse.
>  > 
>  > Is this really true? It seems to me that your BeanShell 
> app can spit out
>  > arbitrary lisp code as a text stream that could be 
> dynamically loaded in
>  > emacs. Can you elaborate on what specifically makes it 
> difficult to do 2-way
>  > interactions with BeanShell apps?
>  > 
> 
> This is what JDE beanshell apps do now. The JDE Lisp function 
> bsh-eval-r
> accepts an arbitrary string of Java code as an argument, e.g., 
> invocation of a static method defined by a JDE app, and sends it
> to the Beanshell's standard input. It then suspends Emacs until it
> receives a response from the Beanshell. bsh-eval-r assumes that
> the response is a Lisp form. When it receives the Lisp form, 
> bsh-eval-r
> evaluates it.


Although this approach is incredibly powerful, it is not generic enough.  It allows an Elisp app to call a Java app, and allows that Java app to return an elisp expression for evaluation (thus affecting the JDE environment). But it does not allow the Java application to see the results of that evaluation; the elisp side of the logic would have to make an addittional call to pass back that result. 

It also does not address (as Paul said before) asynchronous calls. For example, what if you're trying to interface to a Java library that uses listeners/events? That goes from networks protocol libraries (packet received) to GUIs (button pushed). Also, it does not address already existing code that expects to have control of the information flux, making calls to the external "container" to obtain information when needed. 

To solve these problems you would need a true two-way communication path, meaning that somehow you would need Emacs to "listen" for and respond to commands from the Java side. I understand and agree with the statements that a framework like that would be really complex to implement due to the interprocess communication issues. On the other hand, the benefits are great: just look at the amount of plug-ins already written for the JBuilder Open Tools API (not to mention what is also being done for Eclipse, NetBeans, Elixir, JEdit, etc.):

http://www.kylecordes.com/jbot/
http://www.borland.com/jbuilder/resources/jbopentools.html
http://jbopentools.sourceforge.net/


Granted, some (maybe most) of these tools could also be ported to JDE/Emacs using plain elisp/BeanShell. But it would still require a lot of duplicated "glue" code that could be formalized (as Sandip suggested) to make it easier for non-Lisp programmers.

Even if we forget about two-way communication capabilities for a while, having a more framework-oriented standard for  adding Java extensions to JDE would be highly beneficial. JDE could have an "/extensions" directory where it would search for extension jar files. They would be automatically loaded at BeanShell start-up time, and appropriate menu entries/elisp wrappers would be generated using Java Reflection or a config file. When activating the extension code in response to a user command, JDE would pass to it the current environment info (file name, cursor position, text in the active region) - if two-way communication is implemented, an API would be provided to allow the Java code to ask for this information directly.

There is a lot of cool stuff out there - code beautifiers, UML browsers, refactoring tools, lint tools, network protocol stacks - that could be integrated to JDE by regular Java developers *today* if only they had a framework like that. The challenge is big but so are the benefits...

Regards (and sorry for yet another lengthy e-mail)
    Nascif







> 
> - Paul
> 
> 
> 

Re: Setup of JDE

[Nascif Abousalh-Neto]

Hi Alain,

> I am using JDE for about a year, but only for the editing mode. The
> compilation is done in a xterm using a Makefile. 

You should configure JDE to launch make from Emacs (check jde-build
documentation). This way you can jump directly to the source code from the error
messages - a huge time saver.

> The project is becoming
> more and more complex and I have not been able to implement the
> dependencies into the Makefiles. So I decided to give this a try in the
> JDE environment, but also in vain.

Nope, JDE is not the answer. You need an external tool for that. You can look at Jikes
for dependency rules generation for makefiles. 

Another very good option is JavaMake
(http://http://www.experimentalstuff.com/Technologies/JavaMake/index.html). It can be
integrated with both make and Ant, and is *very* smart about dependency checking - it
actually keeps track of how changes affect the class interface. So changing a method
implementation or a private method won't trigger the recompilation of client classes,
but adding an argument to a public method will (and only of the callers of that
method). 

Regards,
Nascif

Launching JSwat from JDE

[Nascif Abousalh-Neto]

Hi,

I recently completed this package that leverages on the Emacs Java Development
Environment (JDE) configuration options to launch JSwat (a really good open source Java
debugger).

I later realized that JDE already supports the configuration of debuggers other than
JDEbug and jdb; the problem is that JSwat requires some parameters to be in a special
format (e.g. no ending slashes in directory names used in the sourcepath, something
required by JDE but that creates problems for JSwat; and usage of Windows style path
notation) which required further transformations. This package takes care of that.

In the long run I believe the best path is to add hooks to JDE to do those
transformations (or to make JSwat more flexible with parameters passed to it from the
command-line) and use the JDE jde-db-debugger option "other". In the mean time, this
package has been quite helpful.

Enjoy,
Nascif

PS: If anybody has been succesful using jde-db-debugger to start JSwat under Windows,
please send me a cheat sheet :-) For example, to which JDE variable should I add the
JSwat jar file?


===File d:/emacs/dev/jswat.el===
;;; jswat.el
;; $Revision: 0.01 $ 

;; Author: Nascif A. Abousalh Neto <[EMAIL PROTECTED]>
;; Maintainer: Nascif A. Abousalh Neto
;; Keywords: java, debugging, tools
;; Time-stamp: <2001-11-21 14:45:17 nascif>

;; Copyright (C) 1997, 1998, 2000, 2001 Nascif A. Abousalh Neto

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.

; Note: This library implements an Emacs interface to JSwat
; (http://www.bluemarsh.com/java/jswat/), based heavily on the JDEE
; (http://jdee.sunsite.dk/rootpage.html) configuration. The idea is to save time by
; re-using the configuration of one tool (JDEE debugger) to use another similar one
; (JSwat). The target audience is designers that have JDEE
; installed and configured, but want to play with a different debugger.
;
; Usage: (assuming JSwat and JDEE are already installed and configured): 
; 1) Add this library to a directory visible from your load-path
; 2) Add to your .emacs (after the lines that enable JDEE) the line
;   (require 'jswat)
; 3) Customize the variable "jswat-jar" to point to the path of your JSwat jar file
; 4) Your probably don't have to do that, but you may need (in future versions of
;JSwat) to customize "jswat-main-class" to reflect changes in the JSwat main class
;name
; 5) After loading a Java file (with an associated JDEE project file), 
;just call it interactively:
;   M-x jswat 
;
; Problems:
; - Not tested on *nix, only on Windows;
; - Probably won't work with paths that contain a space.
; - Uses JDE 2.2.8 variables that have been deprecated in 2.2.9 (easy to fix)
;

(require 'jde)

(defgroup jswat nil
  "JSwat Options"
  :group 'tools
  :prefix "jswat-")

(defcustom jswat-jar "d:/bin/jswat-1.4.6/jswat-2002.jar"
  "Path to JSwat jar file"
  :group 'jswat
  :type 'file)

(defcustom jswat-main-class "com.bluemarsh.jswat.Main"
  "Main class used to launch JSwat"
  :group 'jswat
  :type 'string)

(defun jswat ()
  "Invokes JSwat using the setup derived from the current JDE session.
   Assumes that Emacs is configured to use a Unix-like (e.g. bash) shell"
  (interactive)
  ;; Java interpreter
  (let* ((buffer (get-buffer-create "*JSwat*"))
 (java-vm (if (eq system-type 'windows-nt)
jde-run-java-vm-w
  jde-run-java-vm))
(jpda-jar (if jde-bug-vm-includes-jpda-p  
  (expand-file-name 
   "lib/tools.jar"
   (jde-normalize-path 'jde-bug-jdk-directory))
(expand-file-name 
 "lib/jpda.jar" (jde-normalize-path
 'jde-bug-jpda-directory
(jswat-classpath (list jpda-jar jswat-jar))
(proj-classpath  (mapcar 'jswat-remove-last-slash (if jde-db-option-classpath
jde-db-option-classpath
jde-global-classpath)))
(proj-sourcepath (mapcar 'jswat-remove-last-slash jde-db-source-directories))
)
(set-buffer buffer)
(erase-buffer)
;; Insert vm call
(setq command java-vm)
;;Insert jswat classpat

jde-parse?

[Nascif Abousalh-Neto]

Title: jde-parse?





Is jde-parse still supported? I does not seems to work anymore; I traced to source code to a call (through Beanshell) to jde.parser.ParserMain.parseFile, but I can't find the Java source code for this class. It is not in jde.jar for sure.

Regards,
    Nascif

RE: relative paths

[Nascif Abousalh-Neto]

Title: RE: relative paths





> -Original Message-
> From: Nick Sieger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 13, 2001 3:25 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]
> Cc: 'jde'
> Subject: RE: relative paths
> 
> 
> Why not put the code to set environment variables and other non-JDE
> variables inside of the project file itself?  It will be 
> executed every time
> a project switch happens, because the contents of the project file are
> evalled.  Thus, there should be no need for defadvice.  BTW, the
> jde-save-project mechanism is smart enough not to clobber 
> custom code when
> the project file is (re-)saved.


I used to do just that a long time ago (before environment variables were supported), be I thought that the recommended approach for project files was to keep them "pure" by using only custom to manipulate its contents.

> 
> A more elegant approach would be if it were possible to 
> prepend and append
> entries to classpath-like JDE variables in project files.  
> Then hierachical
> projects could solve this problem.  One or more higher-level 
> project file
> could set the locations of shared dependencies, and lower-level/more
> specific project files could add individual dependencies to 
> the classpath.


Sounds like a great idea!


> 
> /Nick
> 
> -Original Message-
> From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 13, 2001 2:07 PM
> To: Paul Kinnucan; Stefan Heimann
> Cc: jde
> Subject: RE: relative paths
> 
> 
> We have a large system composed by frameworks and client/server
> applications; these individual projects share many library and output
> directories, hence the need for deep directory structures.
> The point is that the contents of the environment variables 
> must be changed
> to reflect the directory/drive mapping of the current project. Just
> re-evaluating the environment variable is necessary but not 
> sufficient; a
> new value must be calculated (based on the project path) and 
> assigned to the
> variable *before* the variable is evaluated by JDE. This is where the
> defadvice is helpful; it allows me to do just that.
> Here is a scenario: 
> 1) working on project A, PRJ_ROOT variable set to A:/my_proj 
> 2) change to a file in project B 
> 3) project is loaded, triggering defadvice (before load), 
> which changes the
> contents of PRJ_ROOT to B:/my_proj 
> 4) environment variables are evaluated to set the jde 
> variables, leading to
> the desired B:/my_proj/lib/... paths. 
> Is there a different way to do that without using defadvice? 
> This approach
> also gives you the flexibility to change any other 
> environment variable on a
> per project basis, like the name of a log output file, or a 
> temporary drive
> or machine name. Things like that can't be solved by relative paths.
> Thanks, 
> Nascif 
> -Original Message- 
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, August 13, 2001 1:51 PM 
> To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Stefan Heimann 
> Cc: jde 
> Subject: Re: relative paths 
> 
> 
>   
> - Original Message - 
> From: Nascif Abousalh-Neto 
> To: Paul Kinnucan ; Stefan Heimann 
> Cc: jde 
> Sent: Monday, August 13, 2001 11:56 AM 
> Subject: RE: relative paths 
> 
> 
> Hi, 
> Wow, calm down! I was just trying to help. I was not 
> criticizing JDE
> or anything. 
> Anyway, let's see: yes on a second thought I agree 
> that Stefan's
> problem is different then mine, and I agree that creating a 
> prj.el on the
> project root is a much less "esoteric" solution. That is 
> precisely how I use
> pry.el in my projects. I should have recognized that, I apologize.
> But I stand by my assertion that using relative paths 
> can be error
> prone in some scenarios. If they start to  get too big (six, 
> seven layers)
> they become cumbersome and hard to get right, and if you change any
> directory strutcture in your project you have to go back changing all
> affected relative paths. 
>   In my case in particular - which may not be very common - we use
> ClearCase for source control on Windows boxes. That means 
> that I may want to
> work on different project trees with the same structure but mapped to
> different drives (depending on which release/bug fix/view 
> you're working at
> the moment). Yes I could use relative paths, but using 
> defadvice I was able
> to use an environment variable to point to specific points in 
> my project
> tree. So instead of
> ../../../../../lib/proj1/jars 
> ../../../../../out/file1.jar 
&g

RE: relative paths

[Nascif Abousalh-Neto]

Title: RE: relative paths





We have a large system composed by frameworks and client/server applications; these individual projects share many library and output directories, hence the need for deep directory structures.

The point is that the contents of the environment variables must be changed to reflect the directory/drive mapping of the current project. Just re-evaluating the environment variable is necessary but not sufficient; a new value must be calculated (based on the project path) and assigned to the variable *before* the variable is evaluated by JDE. This is where the defadvice is helpful; it allows me to do just that.

Here is a scenario:
1) working on project A, PRJ_ROOT variable set to A:/my_proj
2) change to a file in project B
3) project is loaded, triggering defadvice (before load), which changes the contents of PRJ_ROOT to B:/my_proj
4) environment variables are evaluated to set the jde variables, leading to the desired B:/my_proj/lib/... paths.


Is there a different way to do that without using defadvice? This approach also gives you the flexibility to change any other environment variable on a per project basis, like the name of a log output file, or a temporary drive or machine name. Things like that can't be solved by relative paths.

Thanks,
    Nascif


-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 13, 2001 1:51 PM
To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Stefan Heimann
Cc: jde
Subject: Re: relative paths



 
- Original Message - 
From: Nascif Abousalh-Neto 
To: Paul Kinnucan ; Stefan Heimann 
Cc: jde 
Sent: Monday, August 13, 2001 11:56 AM
Subject: RE: relative paths



Hi, 
    Wow, calm down! I was just trying to help. I was not criticizing JDE or anything. 
    Anyway, let's see: yes on a second thought I agree that Stefan's  problem is different then mine, and I agree that creating a prj.el on the project root is a much less "esoteric" solution. That is precisely how I use pry.el in my projects. I should have recognized that, I apologize.

    But I stand by my assertion that using relative paths can be error prone in some scenarios. If they start to  get too big (six, seven layers) they become cumbersome and hard to get right, and if you change any directory strutcture in your project you have to go back changing all affected relative paths. 

  In my case in particular - which may not be very common - we use ClearCase for source control on Windows boxes. That means that I may want to work on different project trees with the same structure but mapped to different drives (depending on which release/bug fix/view you're working at the moment). Yes I could use relative paths, but using defadvice I was able to use an environment variable to point to specific points in my project tree. So instead of

    ../../../../../lib/proj1/jars 
    ../../../../../out/file1.jar 
  I can have 
    $PROJ_ROOT/lib/proj1/jars 
    $PROJ_ROOT/out/file1.jar 
    Which IMHO is much more readable and easier to maintain. If you need to change the structure of your project you just have one place to change - not every place where you use a relative path.

Well, I have a hard time imagining a situation where I would want to put my jar files six directories below my  source directory. Also, on all the projects I work on, the project directory at the root level is pretty stable (e.g., root/src, root/class/ root/lib/, root/doc/, root/help. There is almost never a change except to add a directory at the root level. So the problem you face has never arisen for me. Even if it did, I'd prefer the relative path approach as it allows other developers to use a common project file without first ensuring that the requisite environment variable(s) are set on each developer's system.

    I only used defadvice on jde-load-project-file because there was no jde hook - and I searched for them, in the source code - that would do what I wanted. I had to ensure that every time a project was (re)loaded that the environment variables would be reset based on the current path. Which hook should I use? Could a new jde hook be created for that purpose?

I don't understand the problem you are trying to solve with defadvice. Environment variables in paths are evaluated by the JDE everytime the path is used, e.g., to generate a compile command, not when the project file is loaded. Thus, if you have a project loaded and you change the environment variable, the next time you compile, the classpath will reflect the new value of the environment variable.

 
- Paul

RE: relative paths

[Nascif Abousalh-Neto]

Title: RE: relative paths





Hi,
    Wow, calm down! I was just trying to help. I was not criticizing JDE or anything.


    Anyway, let's see: yes on a second thought I agree that Stefan's  problem is different then mine, and I agree that creating a prj.el on the project root is a much less "esoteric" solution. That is precisely how I use pry.el in my projects. I should have recognized that, I apologize.

    But I stand by my assertion that using relative paths can be error prone in some scenarios. If they start to  get too big (six, seven layers) they become cumbersome and hard to get right, and if you change any directory strutcture in your project you have to go back changing all affected relative paths.

    In my case in particular - which may not be very common - we use ClearCase for source control on Windows boxes. That means that I may want to work on different project trees with the same structure but mapped to different drives (depending on which release/bug fix/view you're working at the moment). Yes I could use relative paths, but using defadvice I was able to use an environment variable to point to specific points in my project tree. So instead of

    ../../../../../lib/proj1/jars
    ../../../../../out/file1.jar


    I can have


    $PROJ_ROOT/lib/proj1/jars
    $PROJ_ROOT/out/file1.jar


    Which IMHO is much more readable and easier to maintain. If you need to change the structure of your project you just have one place to change - not every place where you use a relative path.

    I only used defadvice on jde-load-project-file because there was no jde hook - and I searched for them, in the source code - that would do what I wanted. I had to ensure that every time a project was (re)loaded that the environment variables would be reset based on the current path. Which hook should I use? Could a new jde hook be created for that purpose?

    Regards,
        Nascif


PS: Sorry for the previous HTML e-mail.



-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 13, 2001 11:24 AM
To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Stefan Heimann
Cc: jde
Subject: Re: relative paths



 
- Original Message ----- 
From: Nascif Abousalh-Neto 
To: Paul Kinnucan ; Stefan Heimann 
Cc: [EMAIL PROTECTED] 
Sent: Monday, August 13, 2001 10:08 AM
Subject: RE: relative paths



Hi Stefan, 
    I had a similar problem to solve, 
His problem is that he does not have prj.el file in his source tree, therefore the JDE resolves relative paths against the current buffer directory. Is that your problem? If so, the solution is simple: put a prj.el file in your source tree at the place you want to be the resolution point, typically at the root of your project directory. See the JDE User's Guide for more information.

and used defadvice and environment variables instead of relative paths (which are very error prone and hard to maintain anyway). In my .emacs I have the followin

In what respect are relative paths hard to maintain or error-prone? My group has been using them for months to develop a major commercial  product without the slightest difficulty. If you have a problem with the JDE's implementation of relative paths, please state the problem in detail and recommend improvements so that others may benefit.  

 
In any case, it is more helpful to explain how to use a feature correctly than to recommend a workaround that depends on defadvice and is more esoteric than the feature it attempts to circumvent.

 
BTW, please try to use plain text when posting  to the JDE list out of consideration for those of us who are using plain text mail programs.

- Paul


;;;{{{ set PTM_VOB and JARS_PATH environment variables 
;;; based on file name of current buffer. 
(setq vob-name "ptm") 
(defun extract-vob-mount-path (path-components path-prefix) 
    "" 
    (if (string= vob-name (car path-components)) 
    (concat path-prefix vob-name) 
    (extract-vob-mount-path (cdr path-components) 
    (concat path-prefix (car path-components) "/")))

) 
(defun set-ptm-vob-var () 
  "Sets the PTM_VOB environment variable to the mounting point directory 
   of the view containing the current buffer. 
   For example: d:/Views/NASCIF_VIEW/ptm" 
  (interactive) 
  (setq vob-mount-path 
    (extract-vob-mount-path (split-string (buffer-file-name) "/") "")) 
  (setenv "PTM_VOB" vob-mount-path) 
  (setenv "JARS_PATH" (concat vob-mount-path "/RunTime/CentrexIP/jars")) 
  (setenv "MI2_APPS" (concat vob-mount-path "/RunTime/CentrexIP/MI2/apps")) 
  (message (getenv "PTM_VOB"))) 
; set PTM_VOB and JARS_PATH env variables based on loaded project 
(defa

RE: relative paths

[Nascif Abousalh-Neto]

Title: RE: relative paths





Hi Stefan,
    I had a similar problem to solve, and used defadvice and environment variables instead of relative paths (which are very error prone and hard to maintain anyway). In my .emacs I have the following:

;;;{{{ set PTM_VOB and JARS_PATH environment variables
;;; based on file name of current buffer.
(setq vob-name "ptm")
(defun extract-vob-mount-path (path-components path-prefix)
    ""
    (if (string= vob-name (car path-components))
            (concat path-prefix vob-name)
        (extract-vob-mount-path (cdr path-components)
                                    (concat path-prefix (car path-components) "/")))

)


(defun set-ptm-vob-var ()
  "Sets the PTM_VOB environment variable to the mounting point directory 
   of the view containing the current buffer. 
   For example: d:/Views/NASCIF_VIEW/ptm"
  (interactive)
  (setq vob-mount-path 
                (extract-vob-mount-path (split-string (buffer-file-name) "/") ""))
  (setenv "PTM_VOB" vob-mount-path)
  (setenv "JARS_PATH" (concat vob-mount-path "/RunTime/CentrexIP/jars"))
  (setenv "MI2_APPS" (concat vob-mount-path "/RunTime/CentrexIP/MI2/apps"))
  (message (getenv "PTM_VOB")))


; set PTM_VOB and JARS_PATH env variables based on loaded project
(defadvice jde-load-project-file (before set-ptm-vob-var-advice
 activate compile)
  "When loading a new project, also resets the PTM_VOB environment variable
   to match the mouting path of the current file"
  (set-ptm-vob-var))
;;;}}}


set-ptm-vob-var sets two environment variables, that depend on my ClearCase View. Their content is set based on the current buffer path, and instead of searching from the leaf up (like in a relative path) I start from the root down until I reach a known segment (the project root directory). I then set this absolute path in an environment variable, which is used by the JDE customization variables.

Good luck,
    Nascif


> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 10, 2001 12:32 AM
> To: Stefan Heimann
> Cc: [EMAIL PROTECTED]
> Subject: Re: relative paths
> 
> 
> At 02:46 AM 8/10/2001 +0200, you wrote:
> >Hi! 
> >
> >I have the following project file:
> >
> 
> This does not look like a project file to me. It looks like a 
> .emacs file.
> I would suspect that you actually do not have a project file 
> in your source
> hierarchy, in which case the JDE would treat relative paths 
> as relative to
> the directory of the current source buffer, which appears to be the
> behavior you are experiencing.
> 
> - Paul
> 
> P.S. using setq to set JDE customization variables usually leads to
> problems. Please read the JDE user's guide section on customizing JDE
> variables.
> 
> >
> >(setq jde-resolve-relative-paths t)
> >(defvar tmp-javacode-dir "~/javacode-tmp")
> >
> >(defvar cp  '("./"
> >  tmp-javacode-dir
> >  "./../../../lib/ejb.jar"
> >  "$JIKESPATH"))
> >
> >(custom-set-variables 
> > '(jde-global-classpath cp)
> > '(jde-compile-option-directory tmp-javacode-dir)  ;; 
> necessary for all the 
> >completion commands
> > '(compile-command (concat "~/root-room-access/build.sh"))
> >)
> >
> >
> >I think I followed the rules described in the documentation, I don't
> >want to use absolute path in my project file. The problem is: When I
> >invoke the comiler, the paths are interpreted relativly to the file I
> >want to compile and not to the project file. Because I don't 
> know what
> >structure my source code directory will habe, I don't see any way to
> >write a portable project file. The solution would be treating the
> >paths relativ to the location of the project file.
> >
> >Any suggestions??
> >
> >By Stefan
> 
> 

RE: JDE and Transmogrify (was RE: jlint, antic or other code clea ning tools)

[Nascif Abousalh-Neto]

Title: JDE and Transmogrify (was RE: jlint, antic or other code cleaning tools)



Hi 
Guillaume,

  -Original Message-From: Guillaume Berche 
  [mailto:[EMAIL PROTECTED]]Sent: Monday, August 06, 2001 
  3:44 AMTo: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Mark 
  MynstedCc: jdeSubject: RE: JDE and Transmogrify (was RE: 
  jlint, antic or other code cleaning tools)
   
  The integration of Transmogrify with an IDE seems to be pretty well 
  designed. It seems a good candidate for integration with JDE. I looked in the 
  past at the integration of JRefactory http://jrefactory.sourceforge.net/csrefactory.html. Althought JRefactory seems more advanced in terms of refactoring 
  features, Transmogrify makes it easier to integrate with IDEs.[Nascif] I got 
  the same impression. I was playing with JRefactory recentely, 
  and the main designer was kind enough to extend it to allow the user to 
  configure gnuclient as a source code viewer. This makes for a nice 
  one-direction integration; you now can, from the UML class diagram interface 
  of JRefactory, launch Emacs to see the source code. But integration on the 
  other direction (Emacs->JRefactory) would be much 
  harder.
   
  Concerning the fact that the parsing is made twice 
  and would cost in terms of performance, [Nascif] Plus 
  the fact that Transmogrify uses a lot of 
  memory
   in the 
  short term I would rather approach the use of Transmogrify as an explicit 
  action by the developper rather than an agent warning you constantly of 
  improvements you could make to your code. Consequently, we 
  can imagine to only trigger Transmogrify when the developer requires it. I 
  would be very willing to wait a few seconds every time I need a 
  refactoring/check done, and have no performance impact the rest of the 
  time.[Nascif] I agree 100% percent. 
  
   
  Consequently, the integration with Transmogrify would be emacs-driven 
  instead of the other way around. A same stdin/stdout tunnel than the 
  beanshell/JDEbug uses, could be used for this integration. Emacs would issue 
  beanshell instruction to Transmogrify for triggering refactorings, and the JDE 
  implementation of Transmogrify's Hook interface http://transmogrify.sourceforge.net/doc/api/net/sourceforge/transmogrify/hook/Hook.html  would issue lisp requests to emacs and parse the results to 
  return them to Transmogrify (such as data about current selection)[Nascif] I 
  wonder if the BeanShell instance created by JDEbug could be re-used, shaving 
  some seconds out of the start-up time. Having two JVMs running under 
  Emacs/JDE will take a lot of 
  resources...
   
  I believe it might make sense to wait a bit to have 
  Transmogrify stabilize and expand the list of refactorings before integrating 
  with the JDE. Transmogrify is still in beta, and lots of improvements are 
  scheduled ahead.[Nascif] This is the point I disagree with. 
  I think that the earlier JDE is integrated with Transmogrify the more users we 
  will have using it, and thus the more feedback the tool will receive. Open 
  Source projects grow based on feedback, and more users mean a faster 
  evolution. Who knows, we may even have advanced JDE users extending 
  Transmogrify and implementing new refactorings - or reverse-engineering them 
  to a Semantic-based implementation, which I still think is the ideal solution 
  for JDE.
   
  Currently, the project lists the following 
  refactorings: (http://transmogrify.sourceforge.net/doc/userguide.html)
  
  
Rename Symbol--like Rename Variable except it (sort of) 
works for methods, too. Care must be taken when renaming interface or 
overridden methods. 
Extract Method 
Replace Temp With Query 
Inline Temp 
Pull up field [Nascif] Don't forget the lint (which can find 
unused variables, among other things) and code change (which can wrap 
blocks in try-catch exceptions, a functionality that has already been 
required in the JDE mailing list) extensions as well. They are also very 
useful - and already 
  available.
   
   
  Regards,
  Nascif 
  
-Message d'origine-De : Nascif Abousalh-Neto 
[mailto:[EMAIL PROTECTED]]Envoyé : vendredi 3 août 
2001 19:50À : Mark MynstedCc : 
[EMAIL PROTECTED]Objet : JDE and Transmogrify (was RE: jlint, 
antic or other code cleaning tools)
I was just checking the development notes, and here is what 
it mentions about integrating Transmogrify with other IDE's (already 
integrates with Forte and JBuilder):
"The Hook interface If you want to 
plug Transmogrify into a different pure-java IDE, all you have to do is 
extend Hook and implement the abstract methods according to the IDEs plug-in 
architecture. The IDE must have a few things exposed in its plug-in 
architecture, but we feel these are fairly standard. 
cursor position position of 
beginning and end of the selection current 

RE: Turning off mouse hooks on ECB

[Nascif Abousalh-Neto]

Title: RE: Turning off mouse hooks on ECB





Klaus,
    I'm using the latest official version, 1.32.


    I'll check the toggle-visibility command and the latest version; but I think I really want to keep using deactivate in order to remove the mouse and frame hooks. They don't make sense when you're doing non-code related activities (like working in the shell, playing with dired, e-mail, etc.)

    Regards,
        Nascif


> -Original Message-
> From: Berndl, Klaus [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 05, 2001 11:33 AM
> To: Abousalh-Neto, Nascif [NCRTP:3S60:EXCH]; 'JDE'; 'ECB-Mailing List'
> Subject: RE: Turning off mouse hooks on ECB
> 
> 
> First: I will inspect the code carefully where not a cleanup 
> is done because this should
> be done otherwise it is a bug.
>  
> But second: Which version of ecb you are using? I suppose 
> something <= 1.32?! Ok, latest 1.40beta2 version
> which is available via CVS has a lot of improvements: here is 
> the HISTORY-file.
> You see, there are menus, keybindings, minor-modes etc. AND 
> there is a toggle-visibilty-ecb-windows command.
> Therefore you should not activate/deactivate ECB but only 
> toggle the visibility of the ecb-windows. But this works
> only with latest 1.40beta2. maybe we should realease soon 1.40?!
>  
> Klaus
>  
> HISTORY:
> Version 1.40:
> -
>  
> - New advice for 'other-window-for-scrolling', so all 
> scroll-functions for the
>   "other" window can also scroll the first edit-window if 
> point stays in the
>   second one. (Klaus)
>  
> - ecb-toggle-ecb-windows now preserves the split, the 
> split-amount, the buffer
>   contents, the window starts and current point. (Klaus)
>  
> - Some important changes in the ECB-layout concerning 
> displaying compilation-
>   and temp-buffers. (Klaus):
>  
>   + 'ecb-select-compile-window' has been gone.
>   
>   + 'ecb-use-dedicated-windows' is not longer a 
> user-customizable option but
> it is always set to t, because this is essential for 
> correct working of
> the ecb-layout engine!
>  
>   + 'ecb-compile-window-temporally-enlarge' is now a boolean option.  
>  
>   + Now ECB does all necessary that your edit-window of ECB 
> seems to be a
> normal Emacs frame, especially concerning displaying 
> temp-buffers (like
> help- and completion-buffers) and compilation-buffers.
> 
>   + The variables 'compilation-window-height' and 
> 'temp-buffer-shrink-to-fit'
> (XEmacs) and 'temp-buffer-resize-mode' (GNU Emacs) are 
> now fully supported
> by ECB if no durable compilation-window is shown.
>  
> - New function to toggle visibility of the ECB windows. Now 
> it´s possible to
>   hide all ECB windows without deactivating ECB (see 
> 'ecb-toggle-ecb-windows')
>   (Klaus).
>  
> - ECB is now a global minor mode with it´s own menu "ECB" and 
> it´s own keymap
>   with prefix "C-c .". New function to (de)activate/toggle ECB with
>   'ecb-minor-mode'. (Klaus)
>  
> - Fixed a bug in highlighting current token in the method-buffer when
>   font-lock-mode is nil for the source-buffer. (Klaus)
>  
> - New option for highlighting the method-header in the 
> edit-window after
>   clicking onto the method in the method-window (like 
> Speedbar does). (Klaus)
>  
> - Function for automatically submitting a problem report to 
> the ECB mailing
>   list: ecb-submit-problem-report. (Klaus)
>  
> - Now not only for method-highlighting an idle delay can be 
> set but also for
>   synchronizing the ECB windows with current edit window (see option
>   ecb-window-sync and ecb-window-sync-delay; default is 0.25 
> sec delay)
>   (Klaus).
>  
> - Smarter highlighting of current method (Klaus).
>  
> - All tree-buffers now have as default-directory the current selected
>   directory in the directory buffer. So you can also open 
> files with find-file
>   etc. from within the tree-buffers. (Klaus).
>  
>  
>  
>  Hi,
> I've been using ECB a lot w/ JDE. Typically I activate 
> and deactivate it many times during an Emacs session (to take 
> a better look at shell buffers, dired windows, etc.), and 
> have even created keybinds for that (below).
>  
> The problem is, ecb-deactivate don't seem to do a 
> complete clean-up, specially in the mouse hooks. After I 
> activate/deactivate ECB I start to have very strange mouse 
> (the so called "jump to right destination" behavior, I 
> believe) and frame (popping up) behavior.
>  
> Is there anyway to configure ECB to *really* deactivate 
> the additional mouse/frame behavior?
>  
> Regards,
> Nascif
>  
> ;; ECB keybindings
> (global-set-key "\C-cea" 'ecb-activate)
> (global-set-key "\C-ced" 'ecb-deactivate)
> (global-set-key "\C-ceu" 'ecb-update-directories-buffer)
> (global-set-key "\C-cec" 'ecb-current-buffer-sync)
> (global-set-key "\C-cem" 'ecb-rebuild-methods-buffer)
> (global-set-key "\C-cel" 'ecb-redraw-layout)
> (global-set-key "\C-cec" 'ecb-clear-history)
> (global-s

Turning off mouse hooks on ECB

[Nascif Abousalh-Neto]

Title: RE: Line Wrap problems with ECB



Hi,
    I've been using ECB a lot w/ JDE. 
Typically I activate and deactivate it many times during an Emacs session (to 
take a better look at shell buffers, dired windows, etc.), and have even created 
keybinds for that (below).
 
    The problem is, ecb-deactivate don't 
seem to do a complete clean-up, specially in the mouse hooks. After I 
activate/deactivate ECB I start to have very strange mouse (the so called "jump 
to right destination" behavior, I believe) and frame (popping up) 
behavior.
 
    Is there anyway to configure ECB to 
*really* deactivate the additional mouse/frame behavior?
 
    Regards,
    
Nascif
 
;; 
ECB keybindings(global-set-key "\C-cea" 'ecb-activate)(global-set-key 
"\C-ced" 'ecb-deactivate)(global-set-key "\C-ceu" 
'ecb-update-directories-buffer)(global-set-key "\C-cec" 
'ecb-current-buffer-sync)(global-set-key "\C-cem" 
'ecb-rebuild-methods-buffer)(global-set-key "\C-cel" 
'ecb-redraw-layout)(global-set-key "\C-cec" 
'ecb-clear-history)(global-set-key "\C-ceh" 
'ecb-show-help)

RE: Java Debugger

[Nascif Abousalh-Neto]

Title: RE: Java Debugger





Scott,
    You are probably experiencing delays related to parsing and analysis of semantic information (take a look at the senator package documentation). There are some variables you can configure in your JDE project to greatly reduce this time. In my .emacs I have:

(setq semantic-load-turn-everything-on nil)
(require 'semantic-load)
(global-semanticdb-minor-mode 1)
(add-hook 'speedbar-load-hook (lambda () (require 'semantic-sb)))
(require 'semantic-load)


Regards,
    Nascif


PS: I'm using JDE-2.2.8beta1.
PS: One of the latest versions of senator introduced a semantic information cache that also greatly improves load time.
PS: Take also a look (or browse the JDE mailing list) at the documentation of the jde-which-method. This has been another source of delay that can be easily customized.

-Original Message-
From: Scott Goldstein [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 01, 2001 12:09 PM
To: [EMAIL PROTECTED]
Subject: Re: Java Debugger



When I say slow down, the problem I have with JDE is not that debugging is
slow.  The problem is that just opening a Java buffer is much slower because
there's a lot more processing that JDE requires.  JDE is a great package, but
it's more than I need.


Basically, I'm looking for something like JDEbug without the rest of the
features that JDE has.


Thanks for the help.


Scott


Jason Rumney wrote:


> Scott Goldstein <[EMAIL PROTECTED]> writes:
>
> > I'm looking for a package that enhances java debugging in emacs.  I know
> > JDE has a nice debugging feature, but when I tried it, it slowed down
> > Emacs more that I wanted it to.
>
> JDE has two ways of debugging. JDEbug is more flexible, but does seem
> to slow Emacs down some. The jdb method uses the standard debugging
> facilities in Emacs (the same used to talk to gdb or dbx), I don't
> think you'll get any faster than that.
>
> --
> Jason Rumney <[EMAIL PROTECTED]>

RE: Should the JDE require ECB?

[Nascif Abousalh-Neto]

Title: RE: Should the JDE require ECB?





Hi Paul,
    Great idea, I think that there is a lot of synergy to explore between JDE and ECB. Besides the integration with the project variables (for source directories and other parameters) I think that there is a lot to gain as well in the use of the windows layout engine by JDEbug.

    Thanks,
        Nascif  


-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 12, 2001 1:02 AM
To: [EMAIL PROTECTED]
Subject: Should the JDE require ECB?



Hi all,


I have come to rely on the Emacs Code Browser (ECB) and would like to
integrate it into the JDE. This would entail making ECB yet another
external package required by the JDE. The benefit, however, is that the JDE
would provide facilities for using ECB, such as keybindings and menu items
for toggling ECB off-and-on and setting up ECB to browse
jde-db-source-directories. What do you think?

Experimenting with jdb "threadlocks"

[Nascif Abousalh-Neto]

Title: Experimenting with jdb "threadlocks"





Hi,


    I came across a set of commands on the new JPDA-based jdb that provide powerful tools to debug deadlocks and other thread related issues - as well as providing the basis for nice extensions to JDEbug:

lock    -- print lock info for an object
threadlocks [thread id]   -- print lock info for a thread


    I had to try many combinations until I get them to work, for they are - as I found out after trial and error - VM dependent. They are not supported by the Hotspot VM's; you have to specify -classic.

 I created a test application (attached) that creates a canonic deadlock between two threads. Them I started the application with the following parameters:

/cygdrive/d/dev/deadlock> d:/bin/jdk1.3.1/bin/java -classic -Xnoagent -Djava.compiler=NONE -Xdebug '-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000' -classpath "d:/dev/deadlock;d:/bin/jdk1.3.1/lib/jvm.jar;d:/bin/jdk1.3.1/lib/tools.jar;d:/bin/jdk1.3.1/lib/dt.jar;d:/bin/jdk1.3.1/lib/ir.jar" Deadlock

Starting threads
Joining
Deadlock-1 got lock 1
Deadlock-2 got lock 2   


    The application stars and immediately blocks due to the deadlock. Then I started jdb:


 /cygdrive/d/bin/jdk1.3.1/bin> ./jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8000


    Here is a small session that illustrates the use of "threadlocks":


Initializing jdb...
> threads
Group system:
    (java.lang.Thread)0x3 Signal dispatcher running    
    (java.lang.ref.Reference$ReferenceHandler)0x4 Reference Handler cond. waiti
    (java.lang.ref.Finalizer$FinalizerThread)0x5  Finalizer cond. waiti
Group main:
    (java.lang.Thread)0x1 main  cond. waiti
    (java.lang.Thread)0xa Deadlock-1    waiting in 
    (java.lang.Thread)0xb Deadlock-2    waiting in 
>  suspend
All threads suspended.
>  threadlocks 0xb
Monitor information for thread Deadlock-2:
  Owned monitor: instance of java.lang.Object(id=12)
  Waiting for monitor: instance of java.lang.Object(id=14)
> threadlocks 0xa 
Monitor information for thread Deadlock-1:
  Owned monitor: instance of java.lang.Object(id=14)
  Waiting for monitor: instance of java.lang.Object(id=12)
> threadlocks 0x1
Monitor information for thread main:
  No monitors owned
  Not waiting for a monitor
    
    It is easy to see that there is a deadlock by checking the ownership of monitors in the lines above. I couldn't find a way to correlate the monitor id (id=12 and 14) to actual variable names, but dumping the stack trace of the threads helps:

Deadlock-2[1] where
  [1] Deadlock$2.run (Deadlock.java:51)
  [2] java.lang.Thread.run (Thread.java:484)


    I hope this information is helpful. It would be neat to see a command like that available on the JDEbug Threads buffer.

    Regards,
        Nascif


 


 Deadlock.java

font lock for local variables

[Nascif Abousalh-Neto]

Title: font lock for local variables





Hi,
    Just wondering, would it be possible to use the JDE semantic "knowledge" about a Java file to assign a font lock specifically for local variables?

    This would be wonderful to catch those situations where you create a local variable that "eclipses" a class data member, and end up making an update that loses effect as soon as the scope is closed... Naming conventions help, but if you're reading someone else's code that don't use them, you're out of luck!

    Regards,


        Nascif A.A. Neto


> -Original Message-
> From: Dr. Volker Zell [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 11, 2001 3:56 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Problems with experimental versions of jde and semantic
> 
> 
> Hi Steve
> 
> I'm testing your experimental versions of the following packages:
> 
> jde-1.25-pkg.tar.gz
> semantic-1.05-pkg.tar.gz    
> eieio-1.01-pkg.tar.gz    - seems to work
> 
> 
> Here a couple of problems with your versions of semantic, and jde:
> 
> First of all jde-1.25-pkg.tar.gz is missing 
> jde-package.el/elc. If I copy that from the
> normal jde distribution jde starts up.
> 
> JDE and JDebug docu are not found through menu. This is 
> because first, JDE docu is missing
> from your tar.gz file and second, the lisp code is searching 
> for the html files under the wrong
> directories.
> 
> This fixes the directories:
> 
> 
> diff -c 
> /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el~ 
> /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el
> *** /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el~    
> Sat Mar 10 23:05:58 2001
> --- /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el 
> Sat Mar 10 23:05:58 2001
> ***
> *** 1289,1295 
> (if jde-dir
> (if (and jde-xemacsp
>  (locate-data-directory "jde"))
> !   (expand-file-name "jde-ug.html" jde-dir)
>   (expand-file-name 
> "doc/html/jde-ug/jde-ug.html" jde-dir)   
>   (if (and
>    jde-help
> --- 1289,1295 
> (if jde-dir
> (if (and jde-xemacsp
>  (locate-data-directory "jde"))
> !   (expand-file-name 
> "doc/html/jde-ug/jde-ug.html" jde-dir)
>   (expand-file-name 
> "doc/html/jde-ug/jde-ug.html" jde-dir)   
>   (if (and
>    jde-help
> 
> 
> diff -c 
> /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el~ 
> /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el
> *** 
> /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el~    
> Sat Mar 10 23:07:05 2001
> --- /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el 
> Sat Mar 10 23:07:05 2001
> ***
> *** 2569,2575 
> (if jde-dir
> (if (and jde-xemacsp
>  (locate-data-directory "jde"))
> !   (expand-file-name "jdebug-ug.html" jde-dir)
>   (expand-file-name 
> "doc/html/jdebug-ug/jdebug-ug.html" jde-dir)   
>   (if (and
>    jdebug-help
> --- 2569,2575 
> (if jde-dir
> (if (and jde-xemacsp
>  (locate-data-directory "jde"))
> !   (expand-file-name 
> "doc/html/jdebug-ug/jdebug-ug.html" jde-dir)
>   (expand-file-name 
> "doc/html/jdebug-ug/jdebug-ug.html" jde-dir)   
>   (if (and
>    jdebug-help
> 
> 
> o Also missing is the 
> /usr/local/lib/xemacs/xemacs-packages/etc/jde/doc/tli_rbl/ directory
>   structure. This results in not loading the applet in the 
> JDE help files.
> 
> 
> o The import class and implement interface wizards give 
> errors of the following kind:
> 
> Imported java.applet.Applet
> Invalid function: (macro . #
> "...(6)" [token semantic-overlay-start 
> semantic-token-overlay] 3 
> ("/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic
> -util.elc" . 1624)>)
> 
> 
> This seems to be related with the byte compilation of 
> semantic. It used to work with semantic
> when it's not byte compiled. Anyway both commands produce the 
> desired output but the error messages
> are annoying.
> 
> Ciao
>   Volker
> 
> 

RE: Patch to allow use of remote JavaDoc docsets

[Nascif Abousalh-Neto]

Title: RE: Patch to allow use of remote JavaDoc docsets





Thanks for the useful patch!


FYI, A port of wget for Windows can be downloaded from 
    http://www.interlog.com/~tcharron/wgetwin.html


Cheers,
    Nascif


> -Original Message-
> From: Adrian Robert [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 10:17 PM
> To: [EMAIL PROTECTED]
> Subject: Patch to allow use of remote JavaDoc docsets
> 
> 
> 
> Hi all,
> 
> Two issues with JavaDoc display for symbols (C-c C-v C-w).  
> First, if you
> select "Other" when customizing 'jde-help-docsets' instead of 
> "javadoc",
> lookup will fail (at least on emacs 20.7.1 on Linux) because 
> the 'apply'
> built-in expects a list as its last argument.  (See patch below.)
> 
> Second, at my company we store JavaDoc for the software we 
> develop on an
> internal server and I didn't want to copy it to my machine.  
> So here is an
> initial stab at providing support for remote JavaDoc 
> accessible through http. 
> It only works on systems where the 'wget' utility is 
> available.  Most linux
> systems come with it by default.  Cygwin for Windows doesn't, 
> but it may
> exist.  I'm not sure about others...
> 
> 1) Insert the following into .emacs:
> 
> ; find the html file for a class in a local or remote javadoc tree
> (defun javadoc-find (class docset-dir)
>   (let ((doc-path (concat docset-dir "/" (substitute ?/ ?. 
> class) ".html")))
> (if (or (file-exists-p doc-path)
>       (and (string-match "http:" doc-path)
>    (string-match "200" (shell-command-to-string
>                 (concat "wget " "--spider 
> " doc-path)
>   doc-path)
> ))
> 
> 2) Apply the patch below sitting in the JDE top level 
> directory with "patch
> -p0 < jde-help-patch.patch" (or whatever filename).  It affects
> "lisp/jde-help.el", and fixes both the "Other" bug mentioned 
> above (first
> chunk) and adds the capability to use a remote JavaDoc docset by NOT
> prepending "file://" to the name if it starts with "http:" or 
> "file:" already
> (second chunk).  You'll need to remove the "jde-help.elc" 
> file and recompile
> it if you've already compiled jde.  The patch was generated against
> jde-2.2.6.  (I've attached it as well in case word-wrapping 
> over email mangles
> it.)
> 
> I suppose the "javadoc-find" function could be inserted 
> directly in the
> jde-help.el file, but I wanted to keep the changes to the 
> distribution file to
> a minimum.  It works by calling 'wget' to see if the file 
> exists remotely
> instead of using 'file-exists-p'.
> 
> hope it's useful,
> Adrian
> 
> 
> patch follows
> --- lisp/jde-help.el    Fri Mar  9 17:45:15 2001
> +++ lisp/jde-help-new.el    Fri Mar  9 17:44:48 2001
> @@ -120,7 +120,7 @@
> (apply
>  (jde-help-docset-get-lookup-function docset)
>  class
> -    (jde-help-docset-get-dir docset)
> +    (list (jde-help-docset-get-dir docset))
> jde-help-docsets)))
>   (setq paths (delq nil paths))
>   ;; Return first file found.
> @@ -171,9 +171,12 @@
>    
>  
>  (defun jde-help-show-document (doc-file)
> -  "Actually displays the document."
> +  "Actually displays the document, prepending 'file://' if 
> it appears to be
> local."
>    (if (not (eq doc-file nil))
> -  (browse-url (format "file://%s" doc-file
> +  (cond
> +   ((or (string-match "http:" doc-file) (string-match 
> "file:" doc-file))
> +   (browse-url doc-file))
> +   (t (browse-url (format "file://%s" doc-file ))
>  
>  (defun jde-help-choose-document(doc-files)
>    "Allows the user to select which of the possible 
> documentation files they
> wish to view."
> 

jde-gen-get-set and variable creation position

[Nascif Abousalh-Neto]

Title: jde-gen-get-set and variable creation position





Hi,
    I like the jde-gen-get-set functionality, but some of its the details get in the way every now and then. I constantly find myself "correcting" the output. Here is why:

    - it creates the variable declaration in the middle of the code. As a matter of style, it would be better to create it either at the beggining or the end of the class. Kinda like the jde-import functionality.

    - It could check if the variable already exist and skip the variable declaration if that is the case.


    >> I guess these enhacements would require extensible changes... :-)


    - the javadoc tags generated do not follow the same style of the jde-javadoc commands


    >> changing the template would do the trick?


Regards,
    Nascif


> -Original Message-
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 28, 2001 5:05 PM
> To: Len; [EMAIL PROTECTED]
> Subject: Re: Other beanshell versions?
> 
> 
> At 10:41 AM 3/1/01 +1300, Len wrote:
> >Hi,
> >
> >I notice that the version of beanshell distributed with jde is a bit 
> >behind the most recent stable version at www.beanshell.org. 
> What's the 
> >easiest way to upgrade it: is it just as simple as dropping a new 
> >bsh.jar into the jde lib directory, or are there 
> customizations to the 
> 
> You can do that. It should work unless the latest version has 
> introduced
> incompatibilities with Emac as have previous versions.
> 
> >version distributed with jde that would cause a malfunction 
> if I tried 
> >to use the standard bsh distribution (the mention of "JDE 
> Patch" in the 
> 
> Which version of the JDE are you using. The current version 
> use beanshell
> 1.0 beta unpatched.
> 
> >beanshell startup message makes me wonder). There are extras 
> in the new 
> >version that I'd like to use, but don't want to break jde.
> 
> The patch was needed to fix the Beanshell's command line 
> interface which
> used a java.io method that did not work correctly in JDK 
> 1.1.x. The problem
> occurred only if you were running JDK 1.1.x. Anyway I believe 
> the problem
> was fixed in subsequent versions.
> 
> >
> >Side note: It does seem a little inconsistent that jde 
> requires a few 
> >external lisp packages but comes with a version of 
> beanshell. I'm just 
> >interested why there's the distinction.
> 
> Just history. I developed beanshell.el specifically for the 
> JDE but with
> the idea of ultimately spinning if off as an independent 
> package (hence the
> name). Unfortunately, I built some dependencies on the JDE 
> into the current
> version of beanshell.el and I have to date not had the time 
> or incentive to
> eliminate the dependencies and post it as an independent package.
> 
> - Paul
> 
>