headers
Andy Cooper | 2 May 2003 20:05

JDEE font lock not working - possible semantic token list problem?

I'm using emacs 21.2.1 (i386-msvc-nt5.1.2600)

I've just upgraded from JDEE 2.2.8 -> JDEE 2.3.2. I've got EIEIO 0.17, 
speedbar 0.14 beta 4, semantic 1.4.4 and elib 1.0.

When viewing Java files, syntax hilighting doesn't work. If I switch to
Java mode, it
does work. I've got overlay-fix.el (not that I need it because I'm using
emacs > v20),
but that makes no difference (which I suspected).

semantic/senator is also showing some signs of oddity.

My .emacs file is below.

Any ideas on what I'm doing wrong?

 

---------------------------
;;;
;;; Add load paths
;;;
(add-to-list 'load-path "c:/emacs-21.2/eieio")
(add-to-list 'load-path "c:/emacs-21.2/lisp/elib-1.0")
(add-to-list 'load-path "c:/emacs-21.2/semantic")
(add-to-list 'load-path "c:/emacs-21.2/jde/lisp")
(add-to-list 'load-path "c:/emacs-21.2/speedbar")

;; Set font on Win2K to be Courier New 9 point.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Barclay | 2 May 2003 20:32
Favicon

Re: JDEE font lock not working - possible semantic token list problem?

Andy Cooper wrote:

> I've just upgraded from JDEE 2.2.8 -> JDEE 2.3.2. I've got EIEIO 0.17, 
> speedbar 0.14 beta 4, semantic 1.4.4 and elib 1.0.
>  
> When viewing Java files, syntax hilighting doesn't work. 

And I've noticed that for me only comments are getting colored; all other
text is plain black.

(I think I've got the same version numbers too.)

Daniel
Permalink | Reply | 0 comments |
headers
Andy Cooper | 2 May 2003 21:40

RE: JDEE font lock not working - possible semantic token list problem?

Turns out it was my jde-mode-hook. When I remove that,
things work ok.

-----Original Message-----
From: Daniel Barclay [mailto:Daniel.Barclay <at> fgm.com] 
Sent: Friday, May 02, 2003 1:32 PM
To: Andy Cooper
Cc: jde <at> sunsite.dk
Subject: Re: JDEE font lock not working - possible semantic token list
problem?

Andy Cooper wrote:

> I've just upgraded from JDEE 2.2.8 -> JDEE 2.3.2. I've got EIEIO 0.17,
> speedbar 0.14 beta 4, semantic 1.4.4 and elib 1.0.
>  
> When viewing Java files, syntax hilighting doesn't work.

And I've noticed that for me only comments are getting colored; all
other text is plain black.

(I think I've got the same version numbers too.)

Daniel
Permalink | Reply | 0 comments |
headers
Joshua Spiewak | 4 May 2003 03:08
Picon

Override method issues

Hi all,
 
I have two issues with overriding methods using C-c C-v o.
 
The first issue occurs when there is more than one choice for a method name
(different parameters).  In my particular I have two choices.  Irrespective
of which I choose, the first option is always inserted.  For example, I try
to override the execute method of org.apache.struts.action.Action and am
present with:
 
Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.
 
Possible completions are:
execute(org.apache.struts.action.ActionMapping,
org.apache.struts.action.ActionForm, javax.servlet.ServletRequest,
javax.servlet.ServletResponse) : org.apache.struts.action.ActionForward
throws java.lang.Exception
execute(org.apache.struts.action.ActionMapping,
org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse) :
org.apache.struts.action.ActionForward throws java.lang.Exception
 
I am unable to get JDE to insert the version taking HttpServletRequest.
 
The other issue I am less clear on exactly what causes it.  For some
subclasses, the override fails on something to do with
org.apache.struts.action.ActionErrors:
 
Beanshell expression evaluation error.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kinnucan | 4 May 2003 08:19
Picon
Favicon

Override method issues

Joshua Spiewak writes:
 > Hi all,
 > ,b 
(B > I have two issues with overriding methods using C-c C-v o.
 > ,b 
(B > The first issue occurs when there is more than one choice for a method name
 > (different parameters).  In my particular I have two choices.  Irrespective
 > of which I choose, the first option is always inserted.  For example, I try
 > to override the execute method of org.apache.struts.action.Action and am
 > present with:
 > ,b 
(B > Click <mouse-2> on a completion to select it.
 > In this buffer, type RET to select the completion near point.
 > ,b 
(B > Possible completions are:
 > execute(org.apache.struts.action.ActionMapping,
 > org.apache.struts.action.ActionForm, javax.servlet.ServletRequest,
 > javax.servlet.ServletResponse) : org.apache.struts.action.ActionForward
 > throws java.lang.Exception
 > execute(org.apache.struts.action.ActionMapping,
 > org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest,
 > javax.servlet.http.HttpServletResponse) :
 > org.apache.struts.action.ActionForward throws java.lang.Exception
 > ,b 
(B > I am unable to get JDE to insert the version taking HttpServletRequest.
 > ,b 

(BHi Josh, 

Thank you for reporting this problem. It is due to a bug in JDEE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chitale, Sandip V | 5 May 2003 00:17
Favicon

RE: Override method issues

Paul,

Actually, I have never liked that only reflection is used to get the
info about the
class. Granted, it is the simplest way to get the info which is also
most valid
due to the classloading sematics. However if a class cannot be loaded
for reflection,
JDEE could switch to reading the .class file and get the information
that way.
If the .class file is not available, it could try to parse the .java
file to get the info.

Granted all of these are slightly more difficult things to do but could
be done. It turns
out JDEE already has the neccesary technologies:

1. Reflection using Beanshell JVM.
2. Class file reading using jde-parse-class.el
3. Java source parsing using Semantic

My 2 cents.

regards,
sandip

PS: If I find time I will try to take a shot at it...

-----Original Message-----
From: Paul Kinnucan [mailto:paulk <at> mathworks.com]
(Continue reading)

Permalink | Reply | 501 comments |
headers
Artur Hefczyc | 5 May 2003 10:23
Picon

Test version of guide emacs for java developers

Hello, all

I work on guide "Emacs and JDEE" for java developers.
Now it contains detailed information about installation
process and some sample settings including sample
working .emacs and prj.el file.
I have published it at address:
http://wttools.sourceforge.net/emacs-stuff/emacsandjdee.html

All comments and suggestions are highly required as well
as people willing to write one or more sections about
matters they are experts in.

regards
Artur Hefczyc
--
Artur Hefczyc                                artur.hefczyc <at> plusnet.pl
Open Source Developer
http://geotools.sourceforge.net/
http://wttools.sourceforge.net/
Permalink | Reply | 0 comments |
headers
Eli Daniel | 5 May 2003 20:39

minor JDEE error handling bug

As of version 2.3.2, the JDEE swallows errors it gets as a result of
evaluating beanshell expressions.

A simple fix for this - propagating the underlying error up instead of
swallowing it - is to change beanshell.el line 234 from 

(error "Error evaluating Java expresson. See *Messages* buffer.")))

to
	
	(signal (car eval-error) (cdr eval-error))))

-Eli Daniel
Attachment (winmail.dat): application/ms-tnef, 3336 bytes
Permalink | Reply | 1 comment |
headers
Paul Kinnucan | 6 May 2003 06:21
Picon
Favicon

minor JDEE error handling bug

Hi Eli,

The current way the beanshell handles  errors when attempting to
evaluate Lisp forms resulting from Java expression evaluations is
deliberate. The intention is to not only notify the user that a Lisp
evaluation error has occurred but also to tell the user the
circumstances under which it occurred, namely when the Beanshell tried
to evaluate the result of evaluating a Java expression (assumed to be
a valid Lisp expression). Your change would defeat this aim.

I am puzzled as to why you are not happy with the present
approach. With the present approach, the user is notified that an
error has occurred and is referred to the Messages buffer more
info. How is what you are proposing an improvement over the present
approach?

- Paul

Eli Daniel writes:
 > As of version 2.3.2, the JDEE swallows errors it gets as a result of
 > evaluating beanshell expressions.
 > 
 > A simple fix for this - propagating the underlying error up instead of
 > swallowing it - is to change beanshell.el line 234 from 
 > 
 > (error "Error evaluating Java expresson. See *Messages* buffer.")))
 > 
 > to
 > 	
 > 	(signal (car eval-error) (cdr eval-error))))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kinnucan | 6 May 2003 06:58
Picon
Favicon

RE: Override method issues

Chitale, Sandip V writes:
 > Paul,
 > 
 > Actually, I have never liked that only reflection is used to get the
 > info about the
 > class. Granted, it is the simplest way to get the info which is also
 > most valid
 > due to the classloading sematics. However if a class cannot be loaded
 > for reflection,
 > JDEE could switch to reading the .class file and get the information
 > that way.
 > If the .class file is not available, it could try to parse the .java
 > file to get the info.
 > 
 > Granted all of these are slightly more difficult things to do but could
 > be done. It turns
 > out JDEE already has the neccesary technologies:
 > 
 > 1. Reflection using Beanshell JVM.
 > 2. Class file reading using jde-parse-class.el
 > 3. Java source parsing using Semantic
 > 

Development of the JDEE wizards began well before either semantic or
jde-parse-class was available. I agree it would be nice to update them
to use the newer class info tools that have become available. 
But who will do it and what is the best approach?

I believe that Java reflection should remain the principal tool for
getting information because it does not, unlike semantic and
(Continue reading)

Permalink | Reply | 501 comments |

Gmane