RE: JDE tools to validate Tomcat's web.xml?

[Eric . D . Friedman]

Michael,

XML editing is handled by a completely different set of modes than those
that comprise the JDEE.  From emacs' standpoint, Tomcat's web.xml file is
"just another" XML file -- no special role or relation to java, jdee, etc.
So, you'll need to figure out what's wrong with your emacs configuration
vis-a-vis XML editing, and that's not a JDEE issue.

To take a wild guess, you probably have an error in your load path that is
preventing emacs from finding psgml mode.  If you're not experienced with
emacs lisp, I suggest that you approach the problem incrementally: comment
out most (all?) of your .emacs file and gradually add things back in to the
point where they stop working correctly.  You don't need to keep starting
and stopping emacs:  you can just mark a region that you'd like to evaluate
and M-x evaluate-region.  Or you can post your .emacs file to comp.emacs and
ask for help -- that's a general purpose newsgroup and this list is for JDEE
problems exclusively.

Good luck,
Eric

-Original Message-
From: Michael Coughlan [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 19, 2003 6:38 AM
To: [EMAIL PROTECTED]
Subject: JDE tools to validate Tomcat's web.xml?


Hello all,

What emacs JDE tools are availble for validating a Tomcat web.xml file?

Yesterday, I could edit my web.xml file and see the emacs JDE color coding
the tags blue and data black. Hurray!

As of today, I seem to have lost the pretty colors.

: (

I treied to explicity set xml-mode, but that didn't fix the trouble.

A test edit of foo.java shows that java-mode is still working for java
files. (more pretty colors)

I would love it if my JDE could help to validate my web.xml in some way.
It's a pain to restart tomcat and parse the logs every time. I'd at least
like to get my color coding back.

Thanks,

MPC


Versions:

I am running a Cignys Xwindows Server on Windows XP to connect to a Red Hat
linux box running both the X Client Tomcat 5.

On lunix...
# rpm -qa | grep emacs
emacs-21.2-33

eieio, speedbar, etc are all latest versions, but not the singular beta
install

RE: Implement interface wizard.

[Eric . D . Friedman]

Sounds good to me.

-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 10:16 AM
To: Ole Arndt
Cc: jde
Subject: Re: Implement interface wizard.


Ole Arndt writes:
 > Andy, Eric, Paul,
 > 
 > [EMAIL PROTECTED] writes:
 > 
 > > I'd like to point out that if a method from an interface has no
javadoc, the
 > > javadoc program will copy the documentation from the interface itself.
 > > Consequently, it might be a reasonable default to generate no javadoc
at all
 > > in the implement interface wizard, or at least to make it optional.
 > 
 > an alternative is to use the [EMAIL PROTECTED] inline tag. A combined
 > solution would look like this:
 > 
 > /**
 >  * [EMAIL PROTECTED]
 >  *
 >  * @see package.Class#origMethod
 >  */
 > 


The @see tag seems redundant to me. Also please note that @inheritDoc
will not work for JDK releases earlier than JDK 1.4. So I'd like to
offer an alternative proposal:

If the JDK version used to generate the skeleton method implementation
is earlier than 1.4, generate the skeleton without a comment. Otherwise,
generate the skeleton with the following comment:

  /**
* [EMAIL PROTECTED]
*/

- Paul

aspectj & jde

[Eric . D . Friedman]

Has there been any discussion/interest with the AspectJ folks about pulling
their JDE extensions into the "main" JDE distro?  I know they forked
something called "AJDE" a while back, but now that they're off in
eclipse-land, that's probably not a huge priority (I am speculating, with no
information either way).

In any event, I find myself writing aspectj code in emacs and wishing that
JDE groked the syntax and keywords.  Does anyone else feel my pain?

More productively, I'm curious to hear Paul's thoughts on how JDE should
(not) accomodate language extensions of this kind.  There've been a lot of
these over the years and JDE has wisely ignored most of them, but it's my
opinion that AspectJ is likely to survive longer than some of the
niche-extensions, like SQLJ.  Is it possible to shovel everything associated
with an extension of this kind into a minor mode?  I'm guessing it won't
work with semantic unless someone puts together a grammar for the bovinator,
but could keywords and indentation be done that way?

Apologies for the disconnected thoughts -- I'm not really sure what the
"right" thing to do is in this case.

Eric

RE: jde.sunsite.dk site

[Eric . D . Friedman]

Apropos -- perhaps if the JD Edwards acquisition goes through we can drop
the extra 'e' again.

Only half kidding,
Eric

-Original Message-
From: Sprenger, Karel [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 11:41 PM
To: Jeff Jensen; [EMAIL PROTECTED]
Subject: RE: jde.sunsite.dk site


Jeff,
 
Try http://jdee.sunsite.dk/. The 'e' was added a few month ago.
 
Cheers,
Karel

-Original Message-
From: Jeff Jensen [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 04:55
To: [EMAIL PROTECTED]
Subject: jde.sunsite.dk site



Hi - Has the site been down for days or is it just me (and the only page
that is not working!)?  I have not seen any messages nor updates on the
sunsite.dk page.

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

[Eric D. Friedman]

Daniel,

If you read Paul's note, the problem he's trying to solve arises precisely
because it is too expensive to have a lot of chatter across I/O between
emacs and an external java process.  The solution he's considering --
put the display logic into the java process so as to avoid the I/O --
addresses the problem.  Your proposal - a different window layout managed
by ECB - adds more complexity (by bringing ECB into the mix) without
doing anything to reduce the high cost of I/O between the debugger and its
display.

Eric

In message <[EMAIL PROTECTED]>, "Daniel Hegyi" writes:
: >I think it is practical to use Java to extend Emacs where not much
: >interaction is required between Emacs and the extension, the wizards
: >and the debugger are examples. It may even be possible to provide
: >those extensions with a Java GUI. Pettar Maehlen and I have been
: >discussing the possibility of creating a Java window for JDEbug to display
: >local variable values when stepping through a program. Currently
: >displaying local variables slows down stepping significantly because
: >it involves sending significant amounts of text across the
: >standard I/O channel to Emacs. A separate local variable window
: >that lives in the debugger process instead of the Emacs process would
: >eliminate this bottleneck.
: I think this would be great! JDE is already a very powerful IDE, that is, it 
: has a great deal of functionality. But I'm concerned with the UI aspect of 
: it. Emacs-ers are used to doing M-x all the time, however, I think it could 
: benefit much from some GUI components instead of having to memorize so many 
: functions.
: 
: Regarding the inspection of local vars you may also want to consider 
: displaying them in an ECB window. (Although ECB is not a mandatory component 
: of JDE, it seems like a natural fit for the problem.) Maybe having the 
: option of having either Java GUI or ECB inspection view?
: 
: 
: Regards,
: Daniel
: 
: _
: MSN Photos is the easiest way to share and print your photos: 
: http://photos.msn.com/support/worldwide.aspx
: 

Re: jde-ant completion and bug-fix ?

[Eric D. Friedman]

XML does not allow whitespace between the '<' of the start tag and the
tagname.  In section 3.1, the spec says:

STag ::= '<' Name (S Attribute)* S? '>'

And Ant's parser will not parse XML that does not comply with this
restriction.  I hacked up a build.xml and got this error message:

`The content beginning "< " is not legal markup.  Perhaps the " " () character 
should be a letter.'

So this regexp shouldn't look for w/s (even zero-length w/s) in that
position.  Here is a revised (untested) copy:

  (defcustom jde-ant-target-regexp
  "9rbm0i$nu9$[EMAIL PROTECTED]>, "Max Rydahl Andersen" writes:
: 
: I tried to checkout jde-ant.el from CVS and found that the bug-fix regarding
: target-completion not being able to complete on targets where the name is
: not the first on the line is not in there.
: 
: Here is the fix :)
: 
: (defcustom jde-ant-target-regexp
: "<\\s-*target.+name\\s-*=\\s-*\"\\s-*\\([^\"]+\\)"
:   "*Regular expression used to match target names in Ant build files."
:   :group 'jde-project
:   :type 'string)
: 
: 
: 
: ""Molitor, Stephen"" <[EMAIL PROTECTED]> wrote in message
: A35A461EBB6BD511859E0002A56B89CC44B24C@EXCORP03">news:A35A461EBB6BD511859E0002A56B89CC44B24C@EXCORP03...
: > Max,
: >
: > The bug fix and target-completion stuff is in the latest version of
: > jde-ant.el, in CVS:
: >
: > http://sunsite.dk/cvsweb/jde/lisp/jde-ant.el
: >
: > Paul submitted the chagnes.  I don't think this is in the latest JDE beta
: > distribution, which was made before these changes were submitted.
: >
: > However, it would also be really nice to get Douglas WF Acheson's changes
: in
: > as well, that added the ability to run Ant via Java from the bean shell
: JVM
: > :)
: >
: > Steve Molitor
: > [EMAIL PROTECTED]
: >
: >
: >
: > -Original Message-
: > From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]]
: > Sent: Wednesday, October 24, 2001 2:58 PM
: > To: [EMAIL PROTECTED]
: > Subject: jde-ant completion and bug-fix ?
: >
: >
: > I'm just wondering wether the maintainers of jde-ant.el have incorporated
: > the previously posted bugfixes and addition of target-completion ? It is
: not
: > in the newest jde-ant.el.
: >
: > I have taken the liberty to merge the fixes with the newest jde-ant.el and
: > appended it to this posting.
: >
: > Here is the original "log" from the author.
: >
: > ;; Revision 1.10 2001/10/05 15:04:32  smolitor
: > ;; Added support auto completion of Ant targets in mini-buffer.
: > ;; Added the following defuns and variables:
: > ;;defun jde-ant-find-build-file
: > ;;defun jde-ant-get-target-alist
: > ;;defcustom jde-ant-complete-target
: > ;;defcustom jde-ant-target-regexp
: > ;; Modified defun jde-ant-read-target to use auto-completion, if
: > ;; jde-ant-complete-target is non-nil.
: > ;; Fixed bug in jde-build-ant-command where there was no space between the
: > ant
: > ;; command and the target.
: >
: > ;; fixed jde-ant.el
: >
: > ;; jde-ant.el --- Use Apache Ant to build your JDE projects
: >
: > ;; $Revision: 1.8 $ $Date: 2001/10/04 04:33:54 $
: >
: > ;;
: > ;; Author: Jason Stell | [EMAIL PROTECTED]
: > ;; Created: 19 Oct 2000
: > ;; Version 1.3   19 June 2001
: > ;;
: >
: > ;; This file is not part of Emacs
: >
: > ;; 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 2, 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.
: >
: > ;; You should have received a copy of the GNU General Public License
: > ;; along with this program; see the file COPYING.  If not, write to
: > ;; the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
: > ;; Boston, MA 02111-1307, USA.
: >
: > ;; Commentary:
: > ;; This file defines jde-ant-build and some helper functions.
: > ;; jde-ant-build uses the specified ant program/shell script to
: > ;; execute a specified build file (in the project root).
: > ;;
: > ;;
: > ;; Installation:
: > ;; -- Make sure this file is accessible via your emacs load-path
: > ;; -- Add the following to your .emacs
: > ;;(require 'jde-ant)
: > ;; -- Customize the ant variables, which can be found in the
: > ;;jde-project group
: > ;; -- Optionally create a keybinding for jde-ant-build
: > ;;
: > ;;
: > ;; To do:
: > ;; -- allow interactive ant target/argument specification.
: > ;;{DONE - version 1.1}
: > ;;
: > ;; -- consider using jde-run-java-vm to execute Ant instead of
: > ;;requiring a shell script.
: > ;;
: > ;;
: > ;; Notes:
: > ;; -- The JDE (Java Development Environment for Emacs) can be
: > ;;downloaded at http://sunsite.auc.dk/jde/
: > ;;
: > ;; -- Apache Ant is a Java & XML build system that can 

Re: jde.el and tramp

[Eric D. Friedman]

Dug a little deeper:  On linux, PATH_MAX is 4095; on Solaris it's 1024.

In message <[EMAIL PROTECTED]>, "Eric D. Friedma
n" writes:
: 
: This sounds like a bug that should be fixed in tramp, not in JDE.
: 
: Directory *entry* length maximums are file system dependent too, which
: means that a correct implementation of this hack would require looking at
: the different filesystems that can be mounted on unix and windoze (both of
: which can be nfs clients, of course, and so can mount other filesystems
: through NFS or natively).  A quick look at the header files on my linux
: machine (which includes ufs_fs.h known to work with Solaris and HP/UX,
: as well as ext{2,3}_fs.h, reiser_fs.h etc.) shows that 255 is a popular
: (smile) maximum length for directory entries.
: 
: If the question being asked is "what's the longest legal *path* name" --
: well, on unix that can be very, very large.  I don't know how big exactly,
: but you can definitely create paths that are much bigger than the thread
: below would allow.  To illustrate: I ran this script on my linux machine
: (ext2 filesystem).  Starting at /home/eric, it happily created a directory
: structure /home/eric/0/1/2/3/../4096.  Note also that it had no trouble
: traversing the structure as it went. Note also that each of the nodes
: in this path *could* have been up to 255 characters long.  In sum,
: (255 * 4097) > 100.
: 
: Obviously this is an edge case (although anyone with ClearCase experience
: knows that you can end up dealing with some mighty big pathnames once
: you start poking around in mvfs' "view extended pathnames"), but I
: think it shows why it would be better to solve this problem through some
: other means.  Perhaps the original poster could describe the specific
: issue with tramp in more detail?  Perhaps the folks on the tramp mailing
: list could be enlisted to help resolve it?
: 
: #!/usr/bin/perl
: 
: for my $n (0 .. 4096) {  # upper limit chosen at random (note: *inclusive*)
:   system 'mkdir', "$n";
:   if ($?) { exit 1; }
:   chdir $n;
: }
: 
: In message <[EMAIL PROTECTED]>, Paul Kinnucan writ
>es
: :
: : 
: : Can anyone help with the question raised in the following 
: : thread?
: : 
: : Paul
: : 
: : Jose M Vidal writes:
: :  > 
: :  > Yup, 100 is a hack that works for me. I don't know what the actual
: :  > maximums are.
: :  > 
: :  > On the other hand, we just need to pick a number bigger than the most
: :  > unreasonably long file name but smaller than infinity. H. What is
: :  > 1024?
: :  > 
: :  > Sorry,
: :  > Jose
: :  > 
: :  > 
: :  > On Mon, 22 Oct 2001, [EMAIL PROTECTED] wrote:
: :  > 
: :  > > Jose M Vidal writes:
: :  > >  > 
: :  > >  > jde 1.17 will not work with tramp because of the way it keeps
: :  > >  > trying to go up the directory hierarchy assuming ange-ftp
: :  > >  > usage. It would get into an infinite loop. I fixed this by simply
: :  > >  > constraining the length of the directory to 100 characters. I
: :  > >  > think this makes the code much
: :  > > 
: :  > > Hi Jose,
: :  > > 
: :  > > Why did you choose 100 characters? How do you know that there won't
: :  > > be a valid path somewhere that is more than 100 characters.
: :  > > I'm very leery of hacks like this based on someone's estimate
: :  > > of what is a "reasonable" maximum for some value. I'd rather have
: :  > > the maximum be greater than the maximum of the maximum paths
: :  > > supported by Windows and Unix. Is there such a maximum? I vaguely
: :  > > recall reading somewhere that the limit for Windows paths is
: :  > > 256 characters. If Unix and Windows have constraints on path sizes,
: :  > > I'd be much more comfortable adopting this hack.
: :  > > 
: :  > > - Paul
: :  > > 
: :  > >  > more robust. Here is the changed function (from jde.el):
: :  > >  > 
: :  > >  > 
: :  > >  > (defun jde-find-project-file (dir)
: :  > >  >   "Finds the next project file upwards in the directory tree
: :  > >  > from DIR. Returns nil if it cannot find a project file in DIR
: :  > >  > or an ascendant directory."
: :  > >  >   (let ((file (find jde-project-file-name
: :  > >  > (directory-files dir) :test 'string=)))
: :  > >  > (if file
: :  > >  > (expand-file-name file dir)
: :  > >  >   (if (< (length dir) 100)
: :  > >  >   (if (not (jde-root-dir-p dir))
: :  > >  >   (jde-find-project-file (concat dir "../")))
: :  > >  > 
: :  > >  > Cheer, and thanks for a *great* product,
: :  > >  > Jose
: :  > >  > 
: :  > >  > -- 
: :  > >  > Jose M. Vidal <[EMAIL PROTECTED]>  http://jmvidal.cse.sc.edu
: :  > >  > University of South Carolina  http://www.multiagent.com
: :  > >  > 
: :  > 
: :  > -- 
: :  > Jose M. Vidal <[EMAIL PROTECTED]>  http://jmvidal.cse.sc.edu
: :  > University of South Carolina  http://www.multiagent.com
: :  > 
: : 
: 

Re: jde.el and tramp

[Eric D. Friedman]

This sounds like a bug that should be fixed in tramp, not in JDE.

Directory *entry* length maximums are file system dependent too, which
means that a correct implementation of this hack would require looking at
the different filesystems that can be mounted on unix and windoze (both of
which can be nfs clients, of course, and so can mount other filesystems
through NFS or natively).  A quick look at the header files on my linux
machine (which includes ufs_fs.h known to work with Solaris and HP/UX,
as well as ext{2,3}_fs.h, reiser_fs.h etc.) shows that 255 is a popular
(smile) maximum length for directory entries.

If the question being asked is "what's the longest legal *path* name" --
well, on unix that can be very, very large.  I don't know how big exactly,
but you can definitely create paths that are much bigger than the thread
below would allow.  To illustrate: I ran this script on my linux machine
(ext2 filesystem).  Starting at /home/eric, it happily created a directory
structure /home/eric/0/1/2/3/../4096.  Note also that it had no trouble
traversing the structure as it went. Note also that each of the nodes
in this path *could* have been up to 255 characters long.  In sum,
(255 * 4097) > 100.

Obviously this is an edge case (although anyone with ClearCase experience
knows that you can end up dealing with some mighty big pathnames once
you start poking around in mvfs' "view extended pathnames"), but I
think it shows why it would be better to solve this problem through some
other means.  Perhaps the original poster could describe the specific
issue with tramp in more detail?  Perhaps the folks on the tramp mailing
list could be enlisted to help resolve it?

#!/usr/bin/perl

for my $n (0 .. 4096) {  # upper limit chosen at random (note: *inclusive*)
  system 'mkdir', "$n";
  if ($?) { exit 1; }
  chdir $n;
}

In message <[EMAIL PROTECTED]>, Paul Kinnucan writes
:
: 
: Can anyone help with the question raised in the following 
: thread?
: 
: Paul
: 
: Jose M Vidal writes:
:  > 
:  > Yup, 100 is a hack that works for me. I don't know what the actual
:  > maximums are.
:  > 
:  > On the other hand, we just need to pick a number bigger than the most
:  > unreasonably long file name but smaller than infinity. H. What is
:  > 1024?
:  > 
:  > Sorry,
:  > Jose
:  > 
:  > 
:  > On Mon, 22 Oct 2001, [EMAIL PROTECTED] wrote:
:  > 
:  > > Jose M Vidal writes:
:  > >  > 
:  > >  > jde 1.17 will not work with tramp because of the way it keeps
:  > >  > trying to go up the directory hierarchy assuming ange-ftp
:  > >  > usage. It would get into an infinite loop. I fixed this by simply
:  > >  > constraining the length of the directory to 100 characters. I
:  > >  > think this makes the code much
:  > > 
:  > > Hi Jose,
:  > > 
:  > > Why did you choose 100 characters? How do you know that there won't
:  > > be a valid path somewhere that is more than 100 characters.
:  > > I'm very leery of hacks like this based on someone's estimate
:  > > of what is a "reasonable" maximum for some value. I'd rather have
:  > > the maximum be greater than the maximum of the maximum paths
:  > > supported by Windows and Unix. Is there such a maximum? I vaguely
:  > > recall reading somewhere that the limit for Windows paths is
:  > > 256 characters. If Unix and Windows have constraints on path sizes,
:  > > I'd be much more comfortable adopting this hack.
:  > > 
:  > > - Paul
:  > > 
:  > >  > more robust. Here is the changed function (from jde.el):
:  > >  > 
:  > >  > 
:  > >  > (defun jde-find-project-file (dir)
:  > >  >   "Finds the next project file upwards in the directory tree
:  > >  > from DIR. Returns nil if it cannot find a project file in DIR
:  > >  > or an ascendant directory."
:  > >  >   (let ((file (find jde-project-file-name
:  > >  >   (directory-files dir) :test 'string=)))
:  > >  > (if file
:  > >  >   (expand-file-name file dir)
:  > >  >   (if (< (length dir) 100)
:  > >  > (if (not (jde-root-dir-p dir))
:  > >  > (jde-find-project-file (concat dir "../")))
:  > >  > 
:  > >  > Cheer, and thanks for a *great* product,
:  > >  > Jose
:  > >  > 
:  > >  > -- 
:  > >  > Jose M. Vidal <[EMAIL PROTECTED]>  http://jmvidal.cse.sc.edu
:  > >  > University of South Carolina  http://www.multiagent.com
:  > >  > 
:  > 
:  > -- 
:  > Jose M. Vidal <[EMAIL PROTECTED]>  http://jmvidal.cse.sc.edu
:  > University of South Carolina  http://www.multiagent.com
:  > 
: 

Re: installing JDE on XEmacs

[Eric D. Friedman]

The sumo tarball includes an old copy of the jde.  Delete it from your
system (using the package manager in xemacs) and try again.

In message <[EMAIL PROTECTED]>, Chris Woods writes:
: robert read wrote:
: 
: > * Chris Woods ([EMAIL PROTECTED]) [011003 16:26]:
: >
: >>I've installed on XEmacs using the standard JDE install instructions, and 
: >>have had no problems whatever.
: >>
: > 
: > Was this on a bare bones XEmacs installation with nothing but the
: > xemacs-base and efs packages installed?
: 
: 
: My apologies for incomplete information.
: 
: XEmacs compiled from source on Red Hat Linux 7.1 with the full set of 
: packages installed. I don't like the XEmacs package setup, and simply 
: downloaded and installed the xemacs-sumo bundle.
: 
: cheers,
: Chris
: 

Re: Suggested enhancement to jde-gen-init-cap

[Eric D. Friedman]

I'd like to see this solved in one place.  That is, it'd be great if
configuring the variable Javier mentioned caused *all* fieldname generating
code to make use of it.

In message <000501c14c3b$a7537310$[EMAIL PROTECTED]>, "=?iso-8859-1?Q?Javie
r_S._L=F3pez?=" writes:
: > Is there a similar "variable-convention" for the
: > jde-gen package, or is that what I am proposing?
: > (I have not dug around in the JDE very much.  Just
: > stumbled on a problem and tried to get it fixed, so
: > if a solution is already there I'd rather use it).
: 
: No, it does not exist. 
: 
: Javier
: 

Re: RFE?: Suppress abbrv mode in comments

[Eric D. Friedman]

Actually jde-gen's default "cflow" templates are comment/quote aware.
That is, the tempo-templates include a hook that expands the abbrev
with a control flow template everywhere except when point is inside
of a comment or a double quoted string.

The problem is that the tempo-templates are activated by abbrev-mode,
which is not case sensitive and which doesn't make the text that
triggered the abbrev expansion available to the expander of that text.

There's also no mecahnism through which a template can say "oh wait,
cancel the expansion and leave the text unmolested."

So, abbrev-mode expands abbrevs without regard to case, and the
jde cflow templates are forced to choose one case or the other to
use in contexts (quotes and strings) when the full expansion is not
appropriate.

In sum, this is a minor annoyance, but I'm sure you'll agree that it's
much better than getting if () { } inserted when you're trying to compose
a comment (which is what earlier versions of the templates did before I
added the quote-or-string hook).

Eric

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
: 
: Hi,
: 
: Is it possible to suppress abbreviation mode for comments?  For example, if
: I want to start a sentence in my comment with the word "If", abbreviation
: mode always kicks in and changes it to lowercase "if", thinking that I am
: entering a java keyword.  I can of course Type "If" C-q SPC every time, but
: considering that most often in a comment I one is not typing code, but
: comments, it would be nice if abbreviation was disabled for this.  I suppose
: if you wanted to be really fancy abbreviation mode could ignore everything
: except text inside  blocks.
: 
: Ian
: 
: .
: 

Re: Sorting methods

[Eric D. Friedman]

It should be pretty easy to do this with JavaCC.  Just use one of the
Java grammars that are included with JavaCC and write the parse tree
back out in whatever order you need.  This will make it possible to
preserve javadoc too.  You didn't mention where Visual Age puts field
declarations, but JavaCC should be able to help there too.

You might also want to search the comp.compilers.tools.javacc newsgroup
to see if anyone has already done something similar --> it seems like
the sort of "code beautifying" tool that a compulsive neat freak 
must have been inspired to write at some point.

You could also look at ANTLR for the same stuff: it's a different
parser generator, and its adherents may have done something that would
be helpful to you.

Eric


In message <[EMAIL PROTECTED]>, "Perkens-Golomb, Burkhard" writes:
: I'm looking for a tool to arrange methods in Java sources
: alphabetically.
: 
: I've given away sources to a customer. They've worked with them in
: Visual Age and I want to look at their changes. They don't remember
: all changes they've made so I have to do a diff. But Visual Age stores
: the sources in a database, not in flat files, and if you want normal
: Java files from Visual Age you get them terrible formatted and the
: methods are arranged alphabetically. A diff with my sources is futile.
: 
: I'm looking for a tool to arrange the methods in my sources
: alphabetically.  Of course I could load my sources in Visual Age and
: get them back terrible formatted, too :-) . But I don't have Visual
: Age and I don't want to use it if it's possible without it!
: 
: Could Emacs do it (with semantic, senator etc.)? Or other tools? Any
: ideas or hints?
: 
: TIA,
: 
: Burkhard
: 

Re: ANN: JDE 2.2.9beta2 available... (correct URL)

[Eric D. Friedman]

I got two errors while compiling this release:

1.

While compiling toplevel forms in file /home/eric/emacs/jde/lisp/jde-bug.el:
  !! error (("Given parent class jde-db-debugger is not a class"))

and 2.

While compiling toplevel forms in file /home/eric/emacs/jde/lisp/jde.el:
  !! Malformed property list (((:initarg :version :version string "Compiler version.") 
("Compiler version.")))

In message <[EMAIL PROTECTED]>, Paul Kinnucan writes:
: http://jde.sunsite.dk/rootpage.html#Downloading
: 
: JDE 2.2.9beta2
: 
: ***
: * PLEASE READ *
: ***
: * *
: * This release requires semantic 1.4beta10 (or later),*
: * speedbar 0.13 (or later), and eieio-0.16 (or later, *
: * except eieio-0.17beta1). You can obtain all three   *
: * packages at http://cedet.sourceforge.net*
: * *
: * This release requires version 1.2.2 (or later) of the   *
: * JDK.*
: * *
: * Note: This release does not work with eieio-0.17beta1, but  *
: * it does work with eieio-0.17beta2.  *
: * *
: * This release also requires avltree.el, which is part of the *
: * elib 1.0 package. You can obtain elib at the JDE web site   *
: * in compressed tar (http://sunsite.dk/jde/elib.tar.gz)   *
: * or zip (http://sunsite.dk/jde/elib.zip) format. *
: * *
: * JDEbug runs on Windows 2000 only if Service Pack 2 (or  *
: * later) is installed.*
: * *
: * If syntax-coloring does not work, download and install  *
: * overlay-fix.el from the semantic web site.  *
: * *
: ***
: 
: * The jde-build-ant-command now quotes all path arguments to 
:   accommodate Windows. This change was submitted by 
:   "Kevin Jones" <[EMAIL PROTECTED]>. I don't use Ant so I've
:not tested this change.
: 
: * Replaced the customization variable jde-db-debugger with
:   jde-debugger to be consistent with jde-compiler.
: 
: 

bug in jde-complete

[Eric D. Friedman]

I haven't ever seriously used jde-complete b/c it didn't quite work
(Xemacs, linux) and I could be bothered to find out why.  Well, I
finally looked closer and believe I've found the reason.  

Symptoms:

The problem was that it wouldn't cycle through the possible completions:
instead it would emit a not-very-useful stub which I would then have
to edit.  Also, it complained about an eldoc function not being defined.

so,

java.util.List l = new ArrayList();
l.i[M-x jde-complete-at-point] ===> l.indexOf(java.lang.Object : int);

&& a message about problems with eldoc.

Diagnosis:

The jde-complete.el source has this in it:

;;jde-eldoc for completion signatures
(eval-when-compile (require 'eldoc)
   (require 'senator))

This makes it possible to compile jde-complete.el to jde-complete.elc.
BUT, there's no runtime (require 'eldoc) anywhere in the JDE.  Since I
don't use eldoc (which is part of (x)emacs) in any of my other emacs
stuff, eldoc never gets loaded, and jde-complete's references to eldoc
code do not work.  Hence, jde-complete does not work.

I don't know much about eval-when-compile, but I'm guessing that it
does get evaluated when you load jde-complete from the .el file 
(as opposed to a byte-compiled .elc file).  If this is true, it would
explain why this code might work for those who do not byte compile the
JDE, yet fail for those who do.  [I'm speculating - I haven't looked into
this at all.]

At any rate, since semantic is a requirement for the JDE and since eldoc
is part of (x)emacs, I propose dropping the 'eval-when-compile' bit and
just having plain old 

(require 'eldoc)
(require 'senator)

With this minor change, jde-complete works as advertised and has become
a very handy tool!

Eric

History list jde-interactive-make-arg-history is unbound

[Eric D. Friedman]

When I enable jde-project -> Read Make Args or jde-project -> Ant Read Args
or jde-project -> Ant Read Target, I get errors like the one the subject
`History list jde-interactive-make-arg-history is unbound'

This is with Xemacs, solaris, jde 2.2.8beta1.

Any ideas?

Eric

more on testing JDEbug

[Eric D. Friedman]

Using FSF emacs (will try xemacs shortly) and 2.2.7b10, I was able to
debug the test code I wote about earlier.


I was interested to learn that previous releases of JDEbug had been
setting a debug thread to max priority; I'm testing on linux and on that
platform native threads are implemented as processes.  I did notice
(but did not report) that emacs became quite sluggish when I started
JDEbug, which might meant that it was having trouble getting CPU cycles.
You may recall that earlier yesterday, with the same release, I was
able to debug my application.  At that time I had many more processes
running concurrently on my system than I did when I could not debug later
that same day.  It worked, in other words, when the scheduler wouldn't
let the CPU be monopolized by the MAX_PRIORITY thread, and hung up when
there weren't any non-emacs/jde processes around to challenge "mad max."


So, now that I can do my `basic' debug test, I'm trying some of
the debugging features that I haven't used before and am having new
problems. :-)

I attempted to `watch' the fields in my test class and entered the fully
qualified classname `test.Main' into the appropriate text entry field.
I got the following error:

Error: unable to enable watch request.
 Reason: '-sp' not understood: use either 'for_access' or 'for_modification'.

in the *JDEbug* buffer, this corresponds to the following failed instruction:

JDE> 1 10 watch test.Main  for_modification -sp none

(jde-dbo-command-error
10 "'-sp' not understood: use either 'for_access' or 'for_modification'")

Eric

generating junit tests

[Eric D. Friedman]

I noticed on the JUnit site (http://www.junit.org/) that various IDEs,
including netbeans, have got modules that will generate JUnit tests
for java classes.  See , for example.

Is there any interest in coming up with something similar for the JDE?
Depending on how people feel about the Sun Community License (I am not
a fan), we could study the netbeans implementation and try to leverage it.
Otherwise we could do a clean room implementation under the GPL.

What would people find useful in this respect?  There are some obvious,
low hanging fruit to grab, such as a template to generate (and update)
an AllTests.java suite class for the *Tests.java classes in the current
package.  Less trivial is the generation of actual test code, which is
what the netbeans and other IDE folk claim to have done.

Eric

JDEbug on solaris

[Eric D. Friedman]

Is anyone able to use JDEbug on solaris/xemacs?  This is with 
jde 2.2.6.2

I've followed the instructions for setting up JDEbug and am using
the 1.3.1 beta VM, which is supposed to have fixed the problems with
debugging in hotspot VMs (solaris does not have a "classic" vm).

I coded up a simple class that has a main method that creates a single
instance and invokes a single member method:

String foo(String foo) {
  foo += "y";  // breakpoint set here
  foo += "z";
  return foo;
}

I start up the debugger and do a JDEbug->Processes->Launch Process.
The app starts, but there's no indication that my breakpoint has been
hit (nothing shows up in the Locals buffer, though `foo' is definitely
a local with a value at this point.  

JDEbug->Continue runs the app to completion without hitting my breakpoint.
If I set two breakpoints, the same thing happens, so I'm pretty sure
that it's not a problem of the display not being updated to the breakpoint.

The debugger output follows.

Thanks,
Eric

*** Debugger Output for Process FooBar(5) ***

vm started...
All threads suspended...
Launch command line:
  java -classpath 
/home/eric/classes/xerces.jar:/home/eric/prj/ETJavaFoundation/classes:/home/eric  
FooBar  

Emacs connected to standard IO port 33819 for process FooBar.
Launched VM Java Debug Interface (Reference Implementation) version 1.3 
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.1-beta (Java HotSpot(TM) Client VM, interpreted mode)
initSIOConnect: starting standard I/O handshake.
initSIOConnect: starting SIO connect thread.
Debugger waiting for Emacs to connect to app SIO port 33819.
Debugger connected to standard I/O socket.
Running FooBar.
FooBar process ended.
vm disconnected...

fonts broken in 2.2.6.2

[Eric D. Friedman]

jde 2.2.6.2, xemacs 21, sun sparc solaris 8

Since upgrading the jde, the {} block on my entire class is fontified
as if it were a sexp match.  That is, the background of the whole block
is a nauseating light green.

Has anyone else encountered this?  If so, what did you do to get rid of
it?

Eric