Emacs port to Eclipse

Emacs port to Eclipse

[Sarir Khamsi]

[I search google and did not find anything on this.]

Is there anyone working on a port of GNU Emacs to the Eclipse
framework? If not, has anyone looked at how they could work together?
Thanks.

Sarir

PS This isn't the place to go into Eclipse and why it might be a good
thing. See http://www.eclipse.org/ for more details.

Re: Emacs port to Eclipse

[Kai Grossjohann]

Sarir Khamsi <sarir_a_khamsi@raytheon.com> writes:

> Is there anyone working on a port of GNU Emacs to the Eclipse
> framework? If not, has anyone looked at how they could work together?
> Thanks.

There is RemoteEclipse which allows you to edit files in Emacs and to
compile stuff in Eclipse.

I don't think it is easy to make Emacs work as an Eclipse component:
Eclipse is based on Java, but Emacs is implemented in C.

Of course, the Emacs Way of doing this is to implement Eclipse in
Emacs Lisp ;-)  Actually, what with JDEE and ECB, good progress has
been made already.

Kai

Re: Emacs port to Eclipse

[Thomas L Roche]

Sarir Khamsi Sun, 22 Feb 2004 14:25:29 -0700
> Is there anyone working on a port of GNU Emacs to the Eclipse
> framework? 

"Port" isn't the term I would use: what would probably be needed is a
wrapper. That being said, I dunno anyone working on one, though I
would also love to have one. (It does have Emacs keysets--see

Windows>Preferences>Workbench>Keys>Keyboard Shortcuts
Active Configuration=<Emacs|Emacs 3.0>

but that's not enough !-)

> If not, has anyone looked at how they could work together?

Not particularly, but 2 things come to mind:

* Eclipse can run any COM object in a page (== <view|editor>), so a
  COM wrapper would work

* There is a vi plugin

http://sourceforge.net/projects/viplugin/

  so one might look at how they do what they do.

Re: Emacs port to Eclipse

[Kai Grossjohann]

Thomas L Roche <tlroche@us.ibm.com> writes:

> * There is a vi plugin
>
> http://sourceforge.net/projects/viplugin/
>
>   so one might look at how they do what they do.

It's another vi implementation, so to speak.  At least that's my
understanding.

I'm afraid it might be a lot of work to reimplement Emacs...
Though, perhaps, one could make do with the C portion of it and
reimplement the Lisp interpreter ;-)

Kai

Re: Emacs port to Eclipse

[Joseph Kiniry]

Kai Grossjohann <kai@emptydomain.de> writes:

> Thomas L Roche <tlroche@us.ibm.com> writes:
>
>> * There is a vi plugin
>>
>> http://sourceforge.net/projects/viplugin/
>>
>>   so one might look at how they do what they do.
>
> It's another vi implementation, so to speak.  At least that's my
> understanding.
>
> I'm afraid it might be a lot of work to reimplement Emacs...
> Though, perhaps, one could make do with the C portion of it and
> reimplement the Lisp interpreter ;-)

Actually, initial work on this has already been done years ago.

   http://jemacs.sourceforge.net/

Joe
-- 
Joseph R. Kiniry                    ID 78860581      ICQ 4344804 
SOS Group, University of Nijmegen  http://www.cs.kun.nl/~kiniry/
KindSoftware, LLC                   http://www.kindsoftware.com/
Board Chair: NICE                    http://www.eiffel-nice.org/

Re: Emacs port to Eclipse

[Kai Grossjohann]

Joseph Kiniry <kiniry@acm.org> writes:

>    http://jemacs.sourceforge.net/

Cool.  Thanks for this information.

Kai

Re: Emacs port to Eclipse

[Thomas L Roche]

Sarir Khamsi Sun, 22 Feb 2004 14:25:29 -0700
>>> Is there anyone working on a port of GNU Emacs to the Eclipse
>>> framework? 

Tom Roche 02/23/2004 09:22:10 AM:
>> "Port" isn't the term I would use: what would probably be needed is a
>> wrapper.

or "wanted"

<snip>

>>> If not, has anyone looked at how they could work together?

>> Not particularly, but 2 things come to mind:

>> * Eclipse can run any COM object in a page (== <view|editor>), so a
>>   COM wrapper would work

>> * There is a vi plugin

>> http://sourceforge.net/projects/viplugin/

>>   so one might look at how they do what they do.

Kai Grossjohann <kai@emptydomain.de> writes:
> I'm afraid it might be a lot of work to reimplement Emacs...

Really ?-) My point was, look at how to wrap emacs so as to allow it
to interact with eclipse, NOT reimplement emacs. (Which sounds like a
job for another lifetime :-)

Re: Emacs port to Eclipse

[Gian Uberto Lauri]

>>>>> "TLR" == Thomas L Roche <tlroche@us.ibm.com> writes:

>>> Not particularly, but 2 things come to mind:

>>> * Eclipse can run any COM object in a page (== <view|editor>), so
>>> a COM wrapper would work

COM ? BUUUUUUUUUUUUUUUUU!

Not S.O. independent :> - 

I  think that  gnudoit  could do  the  work, it  lets  you call  Emacs
functions...

 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

Re: Emacs port to Eclipse

[Kai Grossjohann]

Thomas L Roche <tlroche@us.ibm.com> writes:

> Kai Grossjohann <kai@emptydomain.de> writes:
>> I'm afraid it might be a lot of work to reimplement Emacs...
>
> Really ?-) My point was, look at how to wrap emacs so as to allow it
> to interact with eclipse, NOT reimplement emacs. (Which sounds like a
> job for another lifetime :-)

My above comment was made in the context of doing what viPlugin does.  8-)

I'm still not sure how to go about the integration of Emacs and
Eclipse.  RemoteEclipse is one way to do (part of) it.  But I'd think
that it would be most natural for an Emacs user to invoke the
functionality from within Emacs.

For instance, this means that I'd expect to be able to do M-x
find-callers RET RET to find the callers of the method at point.

What do people think?

When I was using Eclipse, it annoyed me to no end that I couldn't use
C-n and C-p to navigate certain popup windows, such as the one from
"find file".  (I forget what the command is called, but I bound it to
C-x C-f.  It pops up a window where I can enter a filename substring,
or a glob-like pattern, and it shows me all directories where this
file is present.  So I can do <down> to select the one I want and hit
RET.  Obviously, I'd expect to be able to do C-n instead of <down>...
But maybe operating Eclipse becomes more bearable with my new Happy
Hacking Keyboard.  I've yet to get used to the new cursor keys on it.)

Kai

Re: Emacs port to Eclipse

[Thomas L Roche]

Kai Grossjohann Tue, 24 Feb 2004 21:38:25 +0100
> I'm still not sure how to go about the integration of Emacs and
> Eclipse. RemoteEclipse is one way to do (part of) it.

Hadn't seen that ...

http://www.raffael.ch/index.jsp?content=page/FTP/RemoteEclipse

> But I'd think that it would be most natural for an Emacs user to
> invoke the functionality from within Emacs.

> For instance, this means that I'd expect to be able to do M-x
> find-callers RET RET to find the callers of the method at point.

Right. FWIW, what I would like to have is emacs in eclipse. I still
want all the happy views, the markers, quick fixes, refactoring
commands, Call Hierarchy, etc. I also want the availability of the
graphical editors (sometimes). But I also want the option to open a
file in an editor that is ... emacs! I.e. not just the right
keybindings, it should have

* a minibuffer, from which I can run elisp normally

* elisp (lack of scripting is IMHO the biggest weakness with eclipse
  right now)

It would be basically my current emacs frame either

* running in the eclipse editor space, with eclipse providing the
  markers in the right and left border (the minibuffer could steal the
  space currently occupied by the tabs). This is what I visualize when
  I say "wrapper": emacs inside eclipse.

* running outside the eclipse frame (as it does now) but communicating
  with eclipse, e.g. getting and understanding the necessary marginal
  inputs from eclipse and displaying them in its own margins. This
  sounds like what RemoteEclipse is starting toward ... hafta take a
  closer look at that ...

Re: Emacs port to Eclipse

[Kai Grossjohann]

Thomas L Roche <tlroche@us.ibm.com> writes:

> Right. FWIW, what I would like to have is emacs in eclipse. I still
> want all the happy views, the markers, quick fixes, refactoring
> commands, Call Hierarchy, etc.

Interesting.  Personally, I'm not that interested in the
visualization.  For me, having the functionality is enough.

But yes, I also want the problem markers, the quick fixes, the
refactoring commands, and the navigation support.

Kai

Re: Emacs port to Eclipse

[Thomas L Roche]

Sarir Khamsi Sun, 22 Feb 2004 14:25:29 -0700
>>> Is there anyone working on a port of GNU Emacs to the Eclipse
>>> framework? 

>>> If not, has anyone looked at how they could work together?

Tom Roche Tue, 24 Feb 2004 09:17:15 -0500
>> Not particularly, but 2 things come to mind:

>> * Eclipse can run any COM object in a page (== <view|editor>), so a
>>   COM wrapper would work

Gian Uberto Lauri Tue, 24 Feb 2004 19:23:49 +0100
> COM ? BUUUUUUUUUUUUUUUUU!

> Not S.O. independent :> - 

That's what I thought, until I heard about

http://www.mozilla.org/projects/xpcom/

http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html
> At the microscopic level, XPCOM and [Microsoft COM] appear
> identical: Both are interface based and require every interface to
> derive from the same base interface. This base interface defines the
> three methods QueryInterface, AddRef, and Release. Despite this
> common ideological heritage, MSCOM and XPCOM components are not
> compatible or interchangeable -- some sort of wrapper or glue code
> is required for the two to operate together. The embedding wrapper
> for Mozilla is a good example. It allows the browser engine to
> appear as an MSCOM ActiveX control while the browser engine
> internally operates on XPCOM components.

> The biggest contrast between XPCOM and MSCOM is that XPCOM
> technology is open source.

Re: Emacs port to Eclipse

[Thomas L Roche]

Tom Roche Tue, 24 Feb 2004 09:17:15 -0500
>> * Eclipse can run any COM object in a page (== <view|editor>), so a
>>   COM wrapper [for Emacs] would work

Gian Uberto Lauri Tue, 24 Feb 2004 19:23:49 +0100
> Not S.O. independent :> - 

Tom Roche 02/27/2004 07:52 PM
> That's what I thought, until I heard about

> http://www.mozilla.org/projects/xpcom/

> http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html
> > The biggest contrast between XPCOM and MSCOM is that XPCOM
> > technology is open source.

Actually, a bigger contrast:

http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html
> XPCOM offers agility across platforms. It supports just about any
> platform that hosts a decent C++ compiler, including:

> * Microsoft Windows (all flavors)
> * Linux
> * HP-UX
> * AIX
> * Solaris
> * OpenVMS
> * MacOS
> * BSD

and that's from an article dated 1 February 2001.