Sandip,
Just tried it out and ran into unexpected behaviour. Essentially the situation is as
follows. I have in my current buffer a class, say B, which extends a class A. In A I
have a protected object logger which is an instance of a Logger class. In class B I
have the code fragment
Hello,
attached is a small library ecb-jde.el which enables you to display
the contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the
Paul == Paul Kinnucan [EMAIL PROTECTED] writes:
Paul Hi Nick,
Paul I am posting my response to your idea of JUCI-based plugins
Paul to the JDEE list because I am interested in getting other
Paul people's
Paul input on this idea.
This sounds like a thoroughly good idea to me. I've
Hi,
I really love the new feature that the frame-split into source and
compilation buffer disappears magically when there was no compilation error.
I would love to see this to be taken a step further: Is it somehow
possible to actually remove the compilation buffer? Or to place it
somewhere
I second those sentiments and that motion.
/ Petter
-Original Message-
From: Mark Pollack [mailto:[EMAIL PROTECTED]]
Sent: den 19 februari 2003 02:01
To: Paul Kinnucan; Nascif Abousalh-Neto
Cc: [EMAIL PROTECTED]
Subject: RE: JDEE plugins (was JUCI)
Hi,
Just my two cents,
In principal you do the following:
1. Getting the class of current point
2. Introspection with java-code of this class
Here is your code
,
| (defun jde-introspect-javatype-at-point ()
| (interactive)
| (if (jde-open-functions-exist)
| (let* ((thing-of-interest (thing-at-point
On Wed, 19 Feb 2003, Karel Sprenger wrote:
Hello,
Ironically enough, the method ecb-jde-display-class-at-point shows the same
behaviour as Sandip's code when I invoke it with point in the variable
logger in class B.
Of course, this must be because Sandips and my code use the same
Klaus Berndl writes:
IMHO this is much easier than using this somehow clumsy beanshell to
communicate between java and elisp.
Easier for whom? The easiest way to implement a feature does not necessarily
result in the implementation that is easiest to use. For example, your proposal
for
Sprenger, Karel [EMAIL PROTECTED] writes:
Hello,
[...]
Is this a semantic problem?
No.
Completion looks for the logger class type by parsing the current java file.
(jde-parse-declared-type-of) The method is not smart enough to look for it in
the super class or classes within the same
Berndl, Klaus [EMAIL PROTECTED] seems to think that:
[ ... ]
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or
Hi,
Javier S. Lopez wrote:
The method jde-compile-finish-kill-buffer takes care of removing the
compilation window from the screen.
if you add this lines:
(run-at-time
3 sec nil 'kill-buffer
(get-buffer-create *compilation*))
to your jde-compile-finish-kill-buffer method
after the lines:
I created this function:
I think it has to be:
(defun jde-compile-finish-kill-buffer (buf msg)
Removes the jde-compile window after a few seconds if no errors.
(save-excursion
(set-buffer buf)
(if (null (or (string-match .*exited abnormally.* msg)
(string-match
On Wed, 19 Feb 2003, Diez B. Roggisch wrote:
Hi,
Javier S. Lopez wrote:
The method jde-compile-finish-kill-buffer takes care of removing the
compilation window from the screen.
if you add this lines:
(run-at-time
3 sec nil 'kill-buffer
(get-buffer-create *compilation*))
to
A few more feature people might have missed are -
1. The output of the tool is hyperlinked. In other words by
putting the point on any java type in the output and hitting RET key
Invokes the tool on that type.
2. It attempts to display values of static final variables (including
Private ones).
As a long time Emacs and JDE user (I think I first started using JDE in 1997) I have
to throw in my 2cents and say that I'd be hugely excited with any work made towards
making plugins written in Java easy to integrate with JDE. Until recently I think
Emacs has been unsurpassed as the editor
Bernadl
I am in Buffer A.java. I use ecb-jde-display-class-at-point to show
methods of B.java. But I am still in A.java buffer. How do I tell ecb to
show the methods of A.java.
-Original Message-
From: Berndl, Klaus [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 2:07 AM
snip/
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
OK I got the answer. When you use C-c . 1 and come back to the source
buffer, the methods window changes back to show the methods of the
buffer you are in.
-Original Message-
From: Jayakrishnan Nair [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 9:18 AM
To: [EMAIL
This is interesting. I know you've mentioned it before. If this
would help the JDE project, I could do this fairly easily. We have
the class parsing code already, we just have to tie it into semantic.
But since we are not using the latest Semantic, and as far as I know
we have no immediate
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
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
Ah, thanks for the information. I actually first heard of the JSR from the JLense
team, which produced a Swing equiv to the Eclipse APIs in an effort to produce a more
J2SDK-friendly approach to writing rich client applications. It seems they are on the
JSR in an attempt to better understand
Hi,
You and others have raised two related but separate issues: one is the
need for plugin-in support and the other is a need for a way to extend
the JDEE that requires only Java programming skills. My proposal
addresses the first. I believe Nick Sieger's JUCI addresses the
second. Perhaps Nick
Nascif Abousalh-Neto writes:
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?);
plugin.el might be useful in
Hello to all.
I have been watching some of the email traffic on this newsletter and
I have yet to see a newbie question. Please forgive me if I am asking
the wrong forum.
I am trying to setup XEmacs as my Java IDE and to that effect I have
installed the JDE. My current configuration is as
MP == Mark Pollack [EMAIL PROTECTED] writes:
MP Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of
MP the users of JDEE, but a good Java programmer. If there was some
MP way that I could write JDEE extensions in Java for at least some
MP subset of plug-in functionality that would
PK == Paul Kinnucan [EMAIL PROTECTED] writes:
[...]
4) Based on (3), it can replace direct invocations of the JVM with
jde-eval
calls (which should make it much faster)
PK Yes.
Problem with (4) is how to get the output to a compilation
buffer. When I launch a new JVM process myself,
PK == Paul Kinnucan [EMAIL PROTECTED] writes:
PK Hi, You and others have raised two related but separate issues:
PK one is the need for plugin-in support and the other is a need for
PK a way to extend the JDEE that requires only Java programming
PK skills. My proposal addresses the first. I
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
On Wed, 19 Feb 2003, [EMAIL PROTECTED] wrote:
this plugin architecture may require enough redesign to rethink the
way JDE works now.
One thing that seems prevalent in these thoughts is that the JDE is the
central point of focus for this plugin architecture and the plugin
architecture is
30 matches
Mail list logo
