[Jemacs-info] Using jemacs as an editor framework.

[Matti Katila]

Hi,

I needed a basic editor functionality for our java based software project
and thus I was interested in jemacs. Our need was not to use swing or swt
but our own widget library. Basicly I copied gnu.jemacs.lang.ELisp and
made some changes to start a different "toolkit" (or in my case a one
that was already running). I run into several problems:

- (minor) I couldn't call it anymore emacs, since in gnu.expr.Language had
a default line saying which class is started (gnu.jemacs.lang.ELisp) when
executed. Yeah, it was easy to fix with Language.registerLanguage(...);

- (Ugly) static things that called ELisp from different places. It
took me a while to find all these. If those called some static methods
from ELisp they did started to initialize stuff that produced
StackOverflowError. I fixed this by creating ELispUtil and moved
utility functions to there which seemed to fix the problem.

I will give the patches over here. GNU GPL applies for both.


-Matti

[Per Bothner]

Post by Matti Katila
I needed a basic editor functionality for our java based software project
and thus I was interested in jemacs. Our need was not to use swing or swt
but our own widget library. Basicly I copied gnu.jemacs.lang.ELisp and
made some changes to start a different "toolkit" (or in my case a one
- (minor) I couldn't call it anymore emacs, since in gnu.expr.Language had
a default line saying which class is started (gnu.jemacs.lang.ELisp) when
executed.

So? It's still the same language, isn't it? I.e. if what you're doing
is support a different toolkit, you should look at how JEmacs handles
switching between Swing and SWT. Specifically:
gnu.jemacs.buffer.EToolkit, which chooses toolkit based on the
gnu.jemacs.toolkit system property.

Post by Matti Katila
I will give the patches over here. GNU GPL applies for both.

That's not really enough. The Kawa copyright is GPL *or options*,
and contributed code should be compatible with my copyright.
True, since parts of JEmacs are derived from FSF-copyrighted
code, JEmacs is covered by the GPL. But I have some ideas about
GUI programming, and long-term we might want to move some code
from JEmacs-specific to more Kawa-generic.

Therefore I ask you to explicitly assign the copyright of the
code to me (which includes the right for me to re-license the code),
or declare that you're putting the code in the public domain.
You can use the same formulation that Chritian Surlykke does.

In any case, the submitted patch is not suitable. Please
look at how you can solve your problem using the EToolkit class.
I think you'll find you'll need a much simpler patch - maybe
none at all.

[Matti Katila]

Post by Per Bothner

Post by Matti Katila
- (minor) I couldn't call it anymore emacs, since in gnu.expr.Language had
a default line saying which class is started (gnu.jemacs.lang.ELisp) when
executed.

So? It's still the same language, isn't it?

True.

Post by Per Bothner
I.e. if what you're doing is support a different toolkit, you should
look at how JEmacs handles switching between Swing and SWT.
...
In any case, the submitted patch is not suitable. Please
look at how you can solve your problem using the EToolkit class.
I think you'll find you'll need a much simpler patch - maybe
none at all.

Yes, I have looked at EToolkit and it did have too many depencies, e.g.,
it had depencies to menus, frames and buffer. If I'm interested to support
xanalogical text model I can not use that, sorry.

Post by Per Bothner
Therefore I ask you to explicitly assign the copyright of the
code to me (which includes the right for me to re-license the code),

That's ok, if you are willing to take care of my moral rights, i.e., put
in the file header something like "/* Written by name1 and name2". */

[Per Bothner]

Post by Matti Katila
- (Ugly) static things that called ELisp from different places. It
took me a while to find all these. If those called some static methods
from ELisp they did started to initialize stuff that produced
StackOverflowError. I fixed this by creating ELispUtil and moved
utility functions to there which seemed to fix the problem.

I think it's better to figure out why you're getting a
StackOverflowError, and fix that. I may be able to help
if you explain what is going on.

Post by Matti Katila
Yes, I have looked at EToolkit and it did have too many depencies,
e.g.,
it had depencies to menus, frames and buffer. If I'm interested to
support xanalogical text model I can not use that, sorry.

Perhaps you need a new buffer sub-class.

It seems like you're trying to do at least two different things:
(1) a new widget library - which is a gui/presentation/toolkit issue;
(2) xanalogic text - which is a string/data-type issue.

Perhaps it would help if we could separate out these concerns.