Implementing Eclipse's "organize-imports" in Emacs Lisp

Implementing Eclipse's "organize-imports" in Emacs Lisp

[Paul Michael Reilly]

I probably spend half my time doing Java development in Emacs and the
other half in Eclipse.  I once tried to get the Eclipse plugin that
talks to Emacsclient to work better for me with only marginal success.
It is an option to revive this effort.  But even if this were to work
nicely, it's appeal is limited to Eclipse developers leaving NetBeans,
IntelliJ, JBuilder, etc. Users out of the solution space.

One of the Eclipse features that I find indispensable is the Organize
Imports feature which analyses the source file to determine if the
import statements need to be pruned, augmented or modified (based on
the .classpath file which is problematic since this file is an Eclipse
artifact).  I would dearly love to have this capability in Emacs.

Have either of the other two Java developers who use Emacs done this
perchance?  :-)  I'm guessing not.

Assuming it does not exist, I'd be inclined to create a Java
application to run in the background which provides an IPC mechanism
to talk to Emacs Lisp.  Then I would develop "features" in this proxy
app for Emacs that are more natural to implement in Java.  I'm
guessing that a "daemon" type app is better than a typical Unix tool
approach (because of painful start-up latencies that won't likely be
solved for a few years ubiquitously)

Anyone feel this is just a totally wrong way to go to solve the
problem?

-pmr

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Lennart Borgman (gmail)]

Paul Michael Reilly wrote:
> I probably spend half my time doing Java development in Emacs and the
> other half in Eclipse.  I once tried to get the Eclipse plugin that
> talks to Emacsclient to work better for me with only marginal success.
> It is an option to revive this effort.  But even if this were to work
> nicely, it's appeal is limited to Eclipse developers leaving NetBeans,
> IntelliJ, JBuilder, etc. Users out of the solution space.
> 
> One of the Eclipse features that I find indispensable is the Organize
> Imports feature which analyses the source file to determine if the
> import statements need to be pruned, augmented or modified (based on
> the .classpath file which is problematic since this file is an Eclipse
> artifact).  I would dearly love to have this capability in Emacs.
> 
> Have either of the other two Java developers who use Emacs done this
> perchance?  :-)  I'm guessing not.
> 
> Assuming it does not exist, I'd be inclined to create a Java
> application to run in the background which provides an IPC mechanism
> to talk to Emacs Lisp.  Then I would develop "features" in this proxy
> app for Emacs that are more natural to implement in Java.  I'm
> guessing that a "daemon" type app is better than a typical Unix tool
> approach (because of painful start-up latencies that won't likely be
> solved for a few years ubiquitously)
> 
> Anyone feel this is just a totally wrong way to go to solve the
> problem?
> 
> -pmr


Why not try to ask this on the JDEE developers list?

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Paul Michael Reilly]

Lennart Borgman (gmail) wrote:
> Paul Michael Reilly wrote:
>> I probably spend half my time doing Java development in Emacs and the
>> other half in Eclipse.  I once tried to get the Eclipse plugin that
>> talks to Emacsclient to work better for me with only marginal success.
>> It is an option to revive this effort.  But even if this were to work
>> nicely, it's appeal is limited to Eclipse developers leaving NetBeans,
>> IntelliJ, JBuilder, etc. Users out of the solution space.
>>
>> One of the Eclipse features that I find indispensable is the Organize
>> Imports feature which analyses the source file to determine if the
>> import statements need to be pruned, augmented or modified (based on
>> the .classpath file which is problematic since this file is an Eclipse
>> artifact).  I would dearly love to have this capability in Emacs.
>>
>> Have either of the other two Java developers who use Emacs done this
>> perchance?  :-)  I'm guessing not.
>>
>> Assuming it does not exist, I'd be inclined to create a Java
>> application to run in the background which provides an IPC mechanism
>> to talk to Emacs Lisp.  Then I would develop "features" in this proxy
>> app for Emacs that are more natural to implement in Java.  I'm
>> guessing that a "daemon" type app is better than a typical Unix tool
>> approach (because of painful start-up latencies that won't likely be
>> solved for a few years ubiquitously)
>>
>> Anyone feel this is just a totally wrong way to go to solve the
>> problem?
>>
>> -pmr
> 
> 
> Why not try to ask this on the JDEE developers list?

Seems like a reasonable idea...

But I will, against my better judgment, make the observation that JDEE 
is pretty much "stuck" and that I have had a lot of problems trying to 
ever find a stable combination of repository based Emacs AND some flavor 
of JDEE so I pretty much abandoned JDEE, Paul's excellent work 
notwithstanding.  Should JDEE become unstuck, I'll revisit making it 
work with the Emacs development code.

-pmr

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Lennart Borgman (gmail)]

Paul Michael Reilly wrote:
> But I will, against my better judgment, make the observation that JDEE 
> is pretty much "stuck" and that I have had a lot of problems trying to 
> ever find a stable combination of repository based Emacs AND some flavor 
> of JDEE so I pretty much abandoned JDEE, Paul's excellent work 
> notwithstanding.  Should JDEE become unstuck, I'll revisit making it 
> work with the Emacs development code.


It looks like there are people trying to get JDEE and the maintenance of 
it into a better state. Please see the JDEE dev list archives.

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Carlos Konstanski]

At Thu, 24 Jan 2008 03:07:25 -0500,
Paul Michael Reilly wrote:
> 
> Lennart Borgman (gmail) wrote:
> > Paul Michael Reilly wrote:
> >> I probably spend half my time doing Java development in Emacs and the
> >> other half in Eclipse.  I once tried to get the Eclipse plugin that
> >> talks to Emacsclient to work better for me with only marginal success.
> >> It is an option to revive this effort.  But even if this were to work
> >> nicely, it's appeal is limited to Eclipse developers leaving NetBeans,
> >> IntelliJ, JBuilder, etc. Users out of the solution space.
> >>
> >> One of the Eclipse features that I find indispensable is the Organize
> >> Imports feature which analyses the source file to determine if the
> >> import statements need to be pruned, augmented or modified (based on
> >> the .classpath file which is problematic since this file is an Eclipse
> >> artifact).  I would dearly love to have this capability in Emacs.
> >>
> >> Have either of the other two Java developers who use Emacs done this
> >> perchance?  :-)  I'm guessing not.
> >>
> >> Assuming it does not exist, I'd be inclined to create a Java
> >> application to run in the background which provides an IPC mechanism
> >> to talk to Emacs Lisp.  Then I would develop "features" in this proxy
> >> app for Emacs that are more natural to implement in Java.  I'm
> >> guessing that a "daemon" type app is better than a typical Unix tool
> >> approach (because of painful start-up latencies that won't likely be
> >> solved for a few years ubiquitously)
> >>
> >> Anyone feel this is just a totally wrong way to go to solve the
> >> problem?
> >>
> >> -pmr
> > 
> > 
> > Why not try to ask this on the JDEE developers list?
> 
> Seems like a reasonable idea...
> 
> But I will, against my better judgment, make the observation that JDEE 
> is pretty much "stuck" and that I have had a lot of problems trying to 
> ever find a stable combination of repository based Emacs AND some flavor 
> of JDEE so I pretty much abandoned JDEE, Paul's excellent work 
> notwithstanding.  Should JDEE become unstuck, I'll revisit making it 
> work with the Emacs development code.
> 
> -pmr

Try this in your .emacs file:

(defun jde-import-fixit ()
  "Combines jde-import-all, jde-import-kill-extra-imports and
jde-import-organize into one easy function call.  Emulates
eclipse's CTRL-SHIFT-O."
  (interactive)
  (jde-import-all)
  (jde-import-kill-extra-imports)
  (jde-import-organize)
  (save-buffer))

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [jdee-users] Implementing Eclipse's "organize-imports" in Emacs Lisp

[Paul Michael Reilly]

Carlos Konstanski wrote:
...
> Try this in your .emacs file:

Excellent.  Thanks for the lead.

-pmr

> (defun jde-import-fixit ()
>   "Combines jde-import-all, jde-import-kill-extra-imports and
> jde-import-organize into one easy function call.  Emulates
> eclipse's CTRL-SHIFT-O."
>   (interactive)
>   (jde-import-all)
>   (jde-import-kill-extra-imports)
>   (jde-import-organize)
>   (save-buffer))

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Yee Keat Phuah]

Hi,

On Jan 24, 2008 4:07 PM, Paul Michael Reilly <pmr-9u8/wbatHBfQT0dZR+AlfA@public.gmane.org> wrote:
> Lennart Borgman (gmail) wrote:
> > Paul Michael Reilly wrote:
[snipped]
> >> Assuming it does not exist, I'd be inclined to create a Java
> >> application to run in the background which provides an IPC mechanism
> >> to talk to Emacs Lisp.  Then I would develop "features" in this proxy
> >> app for Emacs that are more natural to implement in Java.  I'm
> >> guessing that a "daemon" type app is better than a typical Unix tool
> >> approach (because of painful start-up latencies that won't likely be
> >> solved for a few years ubiquitously)

I have the same idea about utilizing some of the eclipse libraries, I
am already using one of them, the ecj eclipse java compiler. In JDEE,
half of the IDE functions are done in java, and another half of them
in emacs lisp, I had the idea of just having emacs as a dumb frontend
to a backend process which relies on most of the eclipse libraries
(since this is where the momentum is). The only "IPC" mechanism that I
am aware of currently is using beanshell.

Having said that, my experience with both emacs and lisp is very
limited, not to mention my time. Just wondering whether anyone else
have explored this possibility, it will surely ease in maintaining
jdee in the future if we head down this direction.

Cheers,
Phuah Yee Keat

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Tom Tromey]

>>>>> ">" == Yee Keat Phuah <ykphuah@gmail.com> writes:

>> I have the same idea about utilizing some of the eclipse libraries, I
>> am already using one of them, the ecj eclipse java compiler.
[...]

>> Having said that, my experience with both emacs and lisp is very
>> limited, not to mention my time. Just wondering whether anyone else
>> have explored this possibility, it will surely ease in maintaining
>> jdee in the future if we head down this direction.

There's eclim, a similar idea applied to vim:

http://eclim.sourceforge.net/

I haven't tried it but I believe this runs a headless eclipse (the
whole thing AFAICT) in the background.  That seems a bit heavyweight,
but OTOH perhaps they have done all the hard work already.

Tom

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Tassilo Horn]

Tom Tromey <tromey@redhat.com> writes:

Hi Tom,

> There's eclim, a similar idea applied to vim:
>
> http://eclim.sourceforge.net/

Hey, that looks really exciting.  Reading through the feature list it
seems they brought most features of eclipse to vim.  The only thing
that's missing there is eclipse's refactoring tool.

> I haven't tried it but I believe this runs a headless eclipse (the
> whole thing AFAICT) in the background.  That seems a bit heavyweight,

Well, better to be a bit heavyweight than to eventually reach a point
where we'd have to say: Sorry, that's not possible with our approach.

> but OTOH perhaps they have done all the hard work already.

Clicking through their repository I'd say that we couldn't reuse much
code.  There seems to be two small shell scripts (a client and a server)
with some small java module that talks to eclipse, but everything else
is done in vimscript.

Anyway, it's exciting to see that it's feasible to control eclipse from
an external app.

Bye,
Tassilo

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Alan Shutko]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Anyway, it's exciting to see that it's feasible to control eclipse from
> an external app.

I've semi-adopted RemoteEclipse[1], which consists of an Eclipse plugin and
some elisp that uses beanshell and java rpc to communicate to Eclipse.
It was limited to pulling the project information (classpath,
directories, etc) from Eclipse, triggering builds, and retrieving error
information into a *compile* buffer.  It didn't attempt to integrate
with Eclipse's project navigation or rafactoring features, instead
allowing JDEE tools to handle it. 

I've somewhat updated it to work with Eclipse 3.x[2] but Eclipse 3
changed to do compilation in a background thread, and that would really
require a fair rework of the whole plugin.  I'd also like to change the
communication path... beanshell to java rpc just bugs me.

I think there are some good ideas in RemoteEclipse, but it might be
easier to start with fresh code.

Footnotes: 
[1]  Formerly at
http://www.raffael.ch/index.jsp?content=page/FTP/RemoteEclipse, but the
site appears to be down.

[2]  http://www.springies.com/~ats/RemoteEclipse.zip

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
I worship the ground that awaits you.

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Tom Tromey]

>>>>> "Paul" == Paul Michael Reilly <pmr@pajato.com> writes:

Paul> Assuming it does not exist, I'd be inclined to create a Java
Paul> application to run in the background which provides an IPC
Paul> mechanism to talk to Emacs Lisp.

Paul> Anyone feel this is just a totally wrong way to go to solve the
Paul> problem?

It makes a lot of sense.  One way to do it would be to just use the
existing Eclipse compiler, with some special driver code to interface
to Emacs.  This would be a big job but would let you expose many of
its nice features.

Or, as Lennart said, there is JDEE.

Tom

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Richard Stallman]

    One of the Eclipse features that I find indispensable is the Organize
    Imports feature which analyses the source file to determine if the
    import statements need to be pruned, augmented or modified (based on
    the .classpath file which is problematic since this file is an Eclipse
    artifact).  I would dearly love to have this capability in Emacs.

It seems to me that the best way to do this is by writing an
external command line program to report the info.  And then writing
an Emacs function to run that program and display the results.

    Have either of the other two Java developers who use Emacs done this
    perchance?  :-)  I'm guessing not.

    Assuming it does not exist, I'd be inclined to create a Java
    application to run in the background which provides an IPC mechanism
    to talk to Emacs Lisp.

Why make the communication so complex?  Why not just fork and exec?

What causes the "startup overhead"?  Is it loading a large analysis
program?  Is it parsing and analyzing your program?

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Assuming it does not exist, I'd be inclined to create a Java
>     application to run in the background which provides an IPC mechanism
>     to talk to Emacs Lisp.
>
> What causes the "startup overhead"?  Is it loading a large analysis
> program?  Is it parsing and analyzing your program?

I don't how much of it is the GUI bits (which presumably Emacs wouldn't
use), but the normal Eclipse app is _extremely_ slow just to start, even
before you load a project.

Of course it _also_ consumes vast amounts of memory, which make having a
persistent process around a bit less inviting ... :-(

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Richard Stallman]

    I don't how much of it is the GUI bits (which presumably Emacs wouldn't
    use), but the normal Eclipse app is _extremely_ slow just to start, even
    before you load a project.

    Of course it _also_ consumes vast amounts of memory, which make having a
    persistent process around a bit less inviting ... :-(

Unless someone wants to write a totally new program, either we
use that one or we don't.

Someone interested in this should actually TRY doing this operation
without the GUI.  Speculating about it is not worth our time.

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Paul Michael Reilly]

Richard Stallman wrote:
...
> It seems to me that the best way to do this is by writing an
> external command line program to report the info.  And then writing
> an Emacs function to run that program and display the results.

My experience is that starting up a Java program appears to take longer 
than a non-Java program, although with each Sun release and with the 
OpenJDK that situation appears to be getting better.  But your point is 
well taken that the simplest approach is the preferable approach until 
it can be verified that the startup time does, in fact, have a negative 
impact.

But this appears to be moot since the JDEE community has addressed the 
problem and might already have a solution.

...
> Why make the communication so complex?  Why not just fork and exec?
> 
> What causes the "startup overhead"?  Is it loading a large analysis
> program?  Is it parsing and analyzing your program?

Yes, it is a parsing and analysis program.

-pmr

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Richard Stallman]

    > What causes the "startup overhead"?  Is it loading a large analysis
    > program?  Is it parsing and analyzing your program?

    Yes, it is a parsing and analysis program.

We are failing to communicate.

My question was: what takes the time?
Is it LOADING and STARTING the analysis program?
Or is it the OPERATION of analyzing your source?

This question might be significant, since we could make
the program store the results of its analysis.

Re: Implementing Eclipse's "organize-imports" in Emacs Lisp

[Klotz, Leigh]

I found this thread because I showed an Eclipse-using colleague
flymake-mode for Java, and he asked about oragnize-imports.

Credmp made flymake-mode for Java use just the ECJ compiler from Eclipse
and EMACS flymake mode.  As for RMS's question below, the startup time
for running Java and the ECJ compiler is small and not that noticeable
when flymake-mode activates it. I don't know if having a perssitent
compiler server a la jde-ecj-server would be useful, especially for
something done rarely and intentionally such as organize-imports.

Here's where I found out about flymake-mode for Java:
http://www.credmp.org/index.php/2007/07/20/on-the-fly-syntax-checking-ja
va-in-emacs/

The credmp.org functions make unnecessary use of JDE and had a couple of
bugs with 22.1.1. 
I've been able to make it work without JDE at all.  Here's what I'm
using:
http://graflex.org/klotz/weblog/2008/02/java-error-highlighting-in-emacs
.html


Leigh.

---------------------------------------

From: 	Richard Stallman
Subject: 	Re: Implementing Eclipse's "organize-imports" in Emacs
Lisp
Date: 	Mon, 28 Jan 2008 16:33:05 -0500

    I don't how much of it is the GUI bits (which presumably Emacs
wouldn't
    use), but the normal Eclipse app is _extremely_ slow just to start,
even
    before you load a project.

    Of course it _also_ consumes vast amounts of memory, which make
having a
    persistent process around a bit less inviting ... :-(

Unless someone wants to write a totally new program, either we
use that one or we don't.

Someone interested in this should actually TRY doing this operation
without the GUI.  Speculating about it is not worth our time.