jEdit

On 23-Jan-07, at 6:14 PM, Zaleski, Matthew (M.E.) wrote:

> Are you positive it is dead or has the JSR process consumed the
> developers attention?  Given that Sun just 'blessed' scripting in Java
> SE 6.0, I'd be surprised to be abandoning Beanshell JSR.

I'm not sure if the JSR will ever lead to anything. There hasn't been  
a new release of BeanShell in years, and the most recent release was  
a beta.

> Some Python-based scripting is intended for inclusion.  I can't put my
> finger on it, but I read about that the last year or so in Dr. Dobb's
> Journal.  I'm guessing Jython is closer to Beanshell than JRuby.

It appears that Jython isn't maintained, either. It lags behind  
CPython by several major revisions.

> very
> time I've glanced at Ruby code, my eyes glaze over.  It looks like
> Python hit by a Perl fanatic; Readability wasn't high on the
> requirements list.

I suggested JRuby because it is in active development and the  
developers were hired by Sun. Also, performance appears to be a goal  
for the JRuby project; they're working on a JVM bytecode compiler.

Personally I don't find either one of Python, Ruby, BeanShell or  
Groovy to be ideal. However as far as readability goes, Ruby is  
pretty good (and much better than Perl); don't confuse being readable  
with being familiar.

Perhaps the best thing to do would be for the jEdit project to fork  
BeanShell and continue maintaining it under the jEdit roof.

Slava

I agree.  There are literally hundreds, perhaps even thousands of macros 
already written in BeanShell.

I'm not up on BSF (http://jakarta.apache.org/bsf/index.html), but maybe 
that would be a decent solution.  It supports a number of scripting 
languages, BeanShell included.

Dale


On Tue, 23 Jan 2007, Slava Pestov wrote:

> Perhaps the best thing to do would be for the jEdit project to fork
> BeanShell and continue maintaining it under the jEdit roof.
>
> Slava
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Hi, in fact maybe my question will seem stupid but I never tried to write
macros
with Jython.
And I don't know how does it looks like.
I know python, but how do it works in jEdit.
Using beanshell you can call methods of the buffer, textarea and every
classes.
How to do that in another language ?

2007/1/24, Slava Pestov <slava@...>:
>
>
> On 23-Jan-07, at 6:14 PM, Zaleski, Matthew (M.E.) wrote:
>
> > Are you positive it is dead or has the JSR process consumed the
> > developers attention?  Given that Sun just 'blessed' scripting in Java
> > SE 6.0, I'd be surprised to be abandoning Beanshell JSR.
>
> I'm not sure if the JSR will ever lead to anything. There hasn't been
> a new release of BeanShell in years, and the most recent release was
> a beta.
>
> > Some Python-based scripting is intended for inclusion.  I can't put my
> > finger on it, but I read about that the last year or so in Dr. Dobb's
> > Journal.  I'm guessing Jython is closer to Beanshell than JRuby.
>
> It appears that Jython isn't maintained, either. It lags behind
> CPython by several major revisions.
>
> > very
> > time I've glanced at Ruby code, my eyes glaze over.  It looks like
> > Python hit by a Perl fanatic; Readability wasn't high on the
> > requirements list.
>
> I suggested JRuby because it is in active development and the
> developers were hired by Sun. Also, performance appears to be a goal
> for the JRuby project; they're working on a JVM bytecode compiler.
>
> Personally I don't find either one of Python, Ruby, BeanShell or
> Groovy to be ideal. However as far as readability goes, Ruby is
> pretty good (and much better than Perl); don't confuse being readable
> with being familiar.
>
> Perhaps the best thing to do would be for the jEdit project to fork
> BeanShell and continue maintaining it under the jEdit roof.
>
> Slava
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> --
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Maybe=20you=20should=20try=20Kawa,=20it's=20a=20scheme-to-bytecode=20compi=
ler=20and
interpreter=20running=20on=20the=20JVM,=20in=20active=20development=20and=20=
it=20already=20is
(language=20wise)=20what=20Ruby=20wants=20to=20become...

David.

-----Original=20Message-----
From:=20jedit-devel-bounces@...
[mailto:jedit-devel-bounces@...=
ava
Pestov
Sent:=2024=20January=202007=2001:04
To:=20jEdit=20dev
Subject:=20Re:=20[=20jEdit-devel=20]=20Removing=20deprecated=20plugin=20AP=
Is,=20BeanShell


On=2023-Jan-07,=20at=206:14=20PM,=20Zaleski,=20Matthew=20(M.E.)=20wrote:

>=20Are=20you=20positive=20it=20is=20dead=20or=20has=20the=20JSR=20process=
=20consumed=20the=20
>=20developers=20attention?=20=20Given=20that=20Sun=20just=20'blessed'=20s=
cripting=20in=20Java

>=20SE=206.0,=20I'd=20be=20surprised=20to=20be=20abandoning=20Beanshell=20=
JSR.

I'm=20not=20sure=20if=20the=20JSR=20will=20ever=20lead=20to=20anything.=20=
There=20hasn't=20been=20a
new=20release=20of=20BeanShell=20in=20years,=20and=20the=20most=20recent=20=
release=20was=20a
beta.

>=20Some=20Python-based=20scripting=20is=20intended=20for=20inclusion.=20=20=
I=20can't=20put=20my

>=20finger=20on=20it,=20but=20I=20read=20about=20that=20the=20last=20year=20=
or=20so=20in=20Dr.=20Dobb's=20
>=20Journal.=20=20I'm=20guessing=20Jython=20is=20closer=20to=20Beanshell=20=
than=20JRuby.

It=20appears=20that=20Jython=20isn't=20maintained,=20either.=20It=20lags=20=
behind=20CPython
by=20several=20major=20revisions.

>=20very
>=20time=20I've=20glanced=20at=20Ruby=20code,=20my=20eyes=20glaze=20over.=20=
=20It=20looks=20like=20
>=20Python=20hit=20by=20a=20Perl=20fanatic;=20Readability=20wasn't=20high=20=
on=20the=20
>=20requirements=20list.

I=20suggested=20JRuby=20because=20it=20is=20in=20active=20development=20an=
d=20the=20developers
were=20hired=20by=20Sun.=20Also,=20performance=20appears=20to=20be=20a=20g=
oal=20for=20the=20JRuby
project;=20they're=20working=20on=20a=20JVM=20bytecode=20compiler.

Personally=20I=20don't=20find=20either=20one=20of=20Python,=20Ruby,=20Bean=
Shell=20or=20Groovy
to=20be=20ideal.=20However=20as=20far=20as=20readability=20goes,=20Ruby=20=
is=20pretty=20good
(and=20much=20better=20than=20Perl);=20don't=20confuse=20being=20readable=20=
with=20being
familiar.

Perhaps=20the=20best=20thing=20to=20do=20would=20be=20for=20the=20jEdit=20=
project=20to=20fork
BeanShell=20and=20continue=20maintaining=20it=20under=20the=20jEdit=20roof=
.

Slava

------------------------------------------------------------------------
-
Take=20Surveys.=20Earn=20Cash.=20Influence=20the=20Future=20of=20IT=20Join=

SourceForge.net's=20Techsay=20panel=20and=20you'll=20get=20the=20chance=20=
to=20share=20your
opinions=20on=20IT=20&=20business=20topics=20through=20brief=20surveys=20-=
=20and=20earn=20cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DD=
EVDE
V
--
-----------------------------------------------
jEdit=20Developers'=20List
jEdit-devel@...
https://lists.sourceforge.net/lists/listinfo/jedit-devel

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The=20service=20is
powered=20by=20MessageLabs.=20For=20more=20information=20on=20a=20proactiv=
e=20anti-virus
service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit:=

http://www.star.net.uk
________________________________________________________________________

This=20message=20is=20from=20FDM=20Group=20Plc,=20and=20may=20contain=20in=
formation=20that=20is=20confidential=20or=20privileged.=20=20If=20you=20ar=
e=20not=20the=20intended=20recipient,=20please=20delete=20the=20message=20=
and=20any=20attachments=20and=20notify=20the=20sender.=20=20This=20email=20=
is=20not=20intended=20to=20create=20legally=20binding=20commitments=20on=20=
behalf=20of=20FDM=20Group=20Plc,=20nor=20do=20its=20contents=20reflect=20t=
he=20corporate=20views=20or=20policies=20of=20FDM.=20=20Any=20unauthorised=
=20disclosure,=20use=20or=20dissemination,=20either=20whole=20or=20partial=
,=20is=20prohibited.=20FDM=20Group=20Plc=20is=20a=20private=20limited=20co=
mpany=20registered=20in=20England=20(Reg.=20No.=202542980).


________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star=20I=
nternet.=20The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________

On 24-Jan-07, at 4:07 AM, David Moss wrote:

> Maybe you should try Kawa, it's a scheme-to-bytecode compiler and
> interpreter running on the JVM, in active development and it  
> already is
> (language wise) what Ruby wants to become...

I enjoy programming in Common Lisp myself and think that for large- 
scale programming it is superior to almost all other languages today,  
but for the simple editor scripting that I do, BeanShell is  
sufficient, despite the nasty boilerplate code one has to write  
sometimes. Language-wise, BeanShell is not a problem for the jEdit core.

One can always write a plugin to integrate Kawa, ABCL or any other  
language anyway.

The problem is that the jEdit core depends on an unmaintained piece  
of software. That is a bad thing. We got rid of the long-dead  
gnu.regexp and com.microstar.xml libraries, which was good. But  
BeanShell has bugs, nobody is updating it, and it is still there.

Slava

My 2p's worth...

given the large investment by jEdit's users with BeanShell, we should
not remove BeanShell completely. We should deprecate its use and then
provide an alternative that has a better future.

We can then begin to remove jEdit's dependency on BeanShell - but I
don't believe we can remove our user's dependency on it.

We should look at the bugs we have with BeanShell and consider what we
really want to fix.

In terms of what the alternative language should be, its always going
to be gamble. Certainly the fact that Sun now employ the jruby guys
suggests that will be around for long enough to become stable.

Ultimately, the 'best' solution could be to enable plugins to provide
scripting support so it can be updated easily in the future - and we
don't have to have the python-ruby-lisp-pascal-basic-factor argument
again and again and again... :)

Given the potential disruption and amount of work involved, we should
consider this a 4.4 item - otherwise there's a risk that 4.3 won't
ever get stable! Sure you could ask why the rush to get a 4.3 stable
version, but there are users out there who won't use a development
branch and want stability. We all know that 4.3 contains some great
stuff above 4.2. The soon the user base moves up, the better.

Again, just my 2p worth.

N

On 24/01/07, Slava Pestov <slava@...> wrote:
>
> On 24-Jan-07, at 4:07 AM, David Moss wrote:
>
> > Maybe you should try Kawa, it's a scheme-to-bytecode compiler and
> > interpreter running on the JVM, in active development and it
> > already is
> > (language wise) what Ruby wants to become...
>
> I enjoy programming in Common Lisp myself and think that for large-
> scale programming it is superior to almost all other languages today,
> but for the simple editor scripting that I do, BeanShell is
> sufficient, despite the nasty boilerplate code one has to write
> sometimes. Language-wise, BeanShell is not a problem for the jEdit core.
>
> One can always write a plugin to integrate Kawa, ABCL or any other
> language anyway.
>
> The problem is that the jEdit core depends on an unmaintained piece
> of software. That is a bad thing. We got rid of the long-dead
> gnu.regexp and com.microstar.xml libraries, which was good. But
> BeanShell has bugs, nobody is updating it, and it is still there.
>
> Slava
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> --
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

=20

> -----Original Message-----
> From: jedit-devel-bounces@...
> [mailto:jedit-devel-bounces@...] On Behalf=20
> Of Nicholas O'Leary
> Sent: Wednesday, January 24, 2007 4:45 AM
> To: jEdit dev
> Subject: Re: [ jEdit-devel ] Removing deprecated plugin APIs,=20
> BeanShell
>=20
> My 2p's worth...
>=20
> given the large investment by jEdit's users with BeanShell,=20
> we should not remove BeanShell completely. We should=20
> deprecate its use and then provide an alternative that has a=20
> better future.
>=20
> We can then begin to remove jEdit's dependency on BeanShell -=20
> but I don't believe we can remove our user's dependency on it.

I agree.  I also think Slava's comment about just forking BeanShell
should be considered.

Given that there is already a plugin that supports multiple scripting
languages, does that give jEdit the flexibility of supporting multiple
scripting languages already?  That would allow the option of deprecating
BeanShell and moving the core of jEdit to one of many alternatives.

The way Jython works is that the backend, instead of being C libraries,
it uses the Java VM.  That grants it access to all Java classes just
like BeanShell.  The resulting code in Jython looks like a combination
of Python and Java.  The same is true of JRuby.  A developer takes the
language spec of Python and Ruby and just implements it using Java
instead of some other language, then adds needed glue logic to access
native methods of the backend engine.  It is really no different than
the fact that CPython easily can access C libraries and DLLs.

Java 6 ships with JavaScript by default.  I don't use JavaScript but is
that another viable script language to consider (given that Sun is
supporting it already)?

https://scripting.dev.java.net/ lists a number of scripting languages
configured to operate in the new Java SE 6 system.

-- Matt

________________________________

	From: Matthieu Casanova
	Sent: Wednesday, January 24, 2007 2:57 AM
	To: jEdit dev
	Subject: Re: [ jEdit-devel ] Removing deprecated plugin APIs,
BeanShell
=09
=09
	Hi, in fact maybe my question will seem stupid but I never tried
to write macros
	with Jython.
	And I don't know how does it looks like.
	I know python, but how do it works in jEdit.
	Using beanshell you can call methods of the buffer, textarea and
every classes.=20
	How to do that in another language ?
=09
	=20

=20

On 1/23/07, Slava Pestov <slava@...> wrote:
>
> Perhaps the best thing to do would be for the jEdit project to fork
> BeanShell and continue maintaining it under the jEdit roof.

That's the best idea so far, I think. It will be easier to FIX
beanshell than get rid of it, I think.  There are a few pieces of
deprecated and ugly pieces of code in beanshell, and we can't make
jEdit ever build cleanly as long as the current beanshell is still
there.

I think that if developers want to get rid of some warnings and modify
the version of beanshell that is in jEdit's SVN, that should be OK.

As for after version 4.3, we can investigate the idea of offering
alternate languages for writing the actions.xml and other pieces of
<code> blocks in our XML files.

2007/1/24, Alan Ezust <alan.ezust@...>:
>
> On 1/23/07, Slava Pestov <slava@...> wrote:
> >
> > Perhaps the best thing to do would be for the jEdit project to fork
> > BeanShell and continue maintaining it under the jEdit roof.
>
> That's the best idea so far, I think. It will be easier to FIX
> beanshell than get rid of it, I think.  There are a few pieces of
> deprecated and ugly pieces of code in beanshell, and we can't make
> jEdit ever build cleanly as long as the current beanshell is still
> there.
>
> I think that if developers want to get rid of some warnings and modify
> the version of beanshell that is in jEdit's SVN, that should be OK.
>
> As for after version 4.3, we can investigate the idea of offering
> alternate languages for writing the actions.xml and other pieces of
> <code> blocks in our XML files.
>

By the way, what are those bugs in beanshell. I don't have too much
problems.
And I would prefer that all scripting in jEdit core remains in one language
:
Beanshell or another, because if some actions are in beanshell, other in
ruby,
javascript, groovy it will be a pain to maintain

This sounds like where BSF comes in (see my previous message on this 
thread).  It is a wrapper to a variety of languages to support such 
scripting in a common way.  The original motivator for BSF was to be able 
to write jsps in ruby.  BeanShell is supported, and about a dozen other 
languages are supported too.  It seems like (yep, I'm talking about things 
where I have little knowledge) that it would be fairly straightforward to 
insert the BSF framework and then use a number of languages for scripting.

Dale


On Wed, 24 Jan 2007, Nicholas O'Leary wrote:

> My 2p's worth...
>
> given the large investment by jEdit's users with BeanShell, we should
> not remove BeanShell completely. We should deprecate its use and then
> provide an alternative that has a better future.
>
> We can then begin to remove jEdit's dependency on BeanShell - but I
> don't believe we can remove our user's dependency on it.
>
> We should look at the bugs we have with BeanShell and consider what we
> really want to fix.
>
> In terms of what the alternative language should be, its always going
> to be gamble. Certainly the fact that Sun now employ the jruby guys
> suggests that will be around for long enough to become stable.
>
> Ultimately, the 'best' solution could be to enable plugins to provide
> scripting support so it can be updated easily in the future - and we
> don't have to have the python-ruby-lisp-pascal-basic-factor argument
> again and again and again... :)
>
> Given the potential disruption and amount of work involved, we should
> consider this a 4.4 item - otherwise there's a risk that 4.3 won't
> ever get stable! Sure you could ask why the rush to get a 4.3 stable
> version, but there are users out there who won't use a development
> branch and want stability. We all know that 4.3 contains some great
> stuff above 4.2. The soon the user base moves up, the better.
>
> Again, just my 2p worth.
>
> N
>
> On 24/01/07, Slava Pestov <slava@...> wrote:
>>
>> On 24-Jan-07, at 4:07 AM, David Moss wrote:
>>
>>> Maybe you should try Kawa, it's a scheme-to-bytecode compiler and
>>> interpreter running on the JVM, in active development and it
>>> already is
>>> (language wise) what Ruby wants to become...
>>
>> I enjoy programming in Common Lisp myself and think that for large-
>> scale programming it is superior to almost all other languages today,
>> but for the simple editor scripting that I do, BeanShell is
>> sufficient, despite the nasty boilerplate code one has to write
>> sometimes. Language-wise, BeanShell is not a problem for the jEdit core.
>>
>> One can always write a plugin to integrate Kawa, ABCL or any other
>> language anyway.
>>
>> The problem is that the jEdit core depends on an unmaintained piece
>> of software. That is a bad thing. We got rid of the long-dead
>> gnu.regexp and com.microstar.xml libraries, which was good. But
>> BeanShell has bugs, nobody is updating it, and it is still there.
>>
>> Slava
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEdit-devel@...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

begin David Moss quotation:
> Maybe you should try Kawa, it's a scheme-to-bytecode compiler and
> interpreter running on the JVM, in active development and it already is
> (language wise) what Ruby wants to become...

I once started a a SchemeShell plugin based on Kawa, but it never got
very far.

-md

Mike,

At=20the=20moment=20I'm=20playing=20with=20kawa=20quite=20a=20lot,=20if=20=
you=20still=20have=20the
code=20let=20me=20have=20it=20and=20see=20if=20I=20can=20make=20it=20into=20=
something=20usable,=20I
was=20already=20planning=20to=20make=20it=20into=20a=20console=20extension=
=20so=20maybe=20I=20can
reuse=20your=20code?

David.

-----Original=20Message-----
From:=20jedit-devel-bounces@...
[mailto:jedit-devel-bounces@...=
ke
Dillon
Sent:=2025=20January=202007=2014:51
To:=20jedit-devel@...
Subject:=20Re:=20[=20jEdit-devel=20]=20Removing=20deprecated=20plugin=20AP=
Is,=20BeanShell

begin=20David=20Moss=20quotation:
>=20Maybe=20you=20should=20try=20Kawa,=20it's=20a=20scheme-to-bytecode=20c=
ompiler=20and=20
>=20interpreter=20running=20on=20the=20JVM,=20in=20active=20development=20=
and=20it=20already=20
>=20is=20(language=20wise)=20what=20Ruby=20wants=20to=20become...

I=20once=20started=20a=20a=20SchemeShell=20plugin=20based=20on=20Kawa,=20b=
ut=20it=20never=20got
very=20far.

-md

------------------------------------------------------------------------
-
Take=20Surveys.=20Earn=20Cash.=20Influence=20the=20Future=20of=20IT=20Join=

SourceForge.net's=20Techsay=20panel=20and=20you'll=20get=20the=20chance=20=
to=20share=20your
opinions=20on=20IT=20&=20business=20topics=20through=20brief=20surveys=20-=
=20and=20earn=20cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DD=
EVDE
V
--
-----------------------------------------------
jEdit=20Developers'=20List
jEdit-devel@...
https://lists.sourceforge.net/lists/listinfo/jedit-devel

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The=20service=20is
powered=20by=20MessageLabs.=20For=20more=20information=20on=20a=20proactiv=
e=20anti-virus
service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit:=

http://www.star.net.uk
________________________________________________________________________

This=20message=20is=20from=20FDM=20Group=20Plc,=20and=20may=20contain=20in=
formation=20that=20is=20confidential=20or=20privileged.=20=20If=20you=20ar=
e=20not=20the=20intended=20recipient,=20please=20delete=20the=20message=20=
and=20any=20attachments=20and=20notify=20the=20sender.=20=20This=20email=20=
is=20not=20intended=20to=20create=20legally=20binding=20commitments=20on=20=
behalf=20of=20FDM=20Group=20Plc,=20nor=20do=20its=20contents=20reflect=20t=
he=20corporate=20views=20or=20policies=20of=20FDM.=20=20Any=20unauthorised=
=20disclosure,=20use=20or=20dissemination,=20either=20whole=20or=20partial=
,=20is=20prohibited.=20FDM=20Group=20Plc=20is=20a=20private=20limited=20co=
mpany=20registered=20in=20England=20(Reg.=20No.=202542980).


________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star=20I=
nternet.=20The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________

begin David Moss quotation:
> At the moment I'm playing with kawa quite a lot, if you still have the
> code let me have it and see if I can make it into something usable, I
> was already planning to make it into a console extension so maybe I can
> reuse your code?

It was in the jEdit CVS and I don't have a copy of it anymore. I don't
know if it made the transition to SVN. That being said, it's probably
also pretty crappy since I wrote it in 2001 or 2002 and I've recently
had to cringe at stuff I wrote in 2004.

-md

Ok,=20i'll=20have=20a=20look=20and=20see=20what=20I=20can=20find=20there=20=
(if=20anything)...=20it=20will=20take=20me=20a=20few=20weeks=20to=20do=20e=
ven=20that=20tho,=20i'm=20away=20at=20the=20moment=20attending=20the=20fun=
eral=20of=20my=20grandfather.

David.


-----Original=20Message-----
From:=20jedit-devel-bounces@...=
e=20Dillon
Sent:=20Fri=201/26/2007=203:14=20PM
To:=20jedit-devel@...
Subject:=20Re:=20[=20jEdit-devel=20]=20Removing=20deprecated=20plugin=20AP=
Is,=20BeanShell
=20
begin=20David=20Moss=20quotation:
>=20At=20the=20moment=20I'm=20playing=20with=20kawa=20quite=20a=20lot,=20i=
f=20you=20still=20have=20the
>=20code=20let=20me=20have=20it=20and=20see=20if=20I=20can=20make=20it=20i=
nto=20something=20usable,=20I
>=20was=20already=20planning=20to=20make=20it=20into=20a=20console=20exten=
sion=20so=20maybe=20I=20can
>=20reuse=20your=20code?

It=20was=20in=20the=20jEdit=20CVS=20and=20I=20don't=20have=20a=20copy=20of=
=20it=20anymore.=20I=20don't
know=20if=20it=20made=20the=20transition=20to=20SVN.=20That=20being=20said=
,=20it's=20probably
also=20pretty=20crappy=20since=20I=20wrote=20it=20in=202001=20or=202002=20=
and=20I've=20recently
had=20to=20cringe=20at=20stuff=20I=20wrote=20in=202004.

-md

-------------------------------------------------------------------------
Take=20Surveys.=20Earn=20Cash.=20Influence=20the=20Future=20of=20IT
Join=20SourceForge.net's=20Techsay=20panel=20and=20you'll=20get=20the=20ch=
ance=20to=20share=20your
opinions=20on=20IT=20&=20business=20topics=20through=20brief=20surveys=20-=
=20and=20earn=20cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DD=
EVDEV
--=20
-----------------------------------------------
jEdit=20Developers'=20List
jEdit-devel@...
https://lists.sourceforge.net/lists/listinfo/jedit-devel

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________


This=20message=20is=20from=20FDM=20Group=20Plc,=20and=20may=20contain=20in=
formation=20that=20is=20confidential=20or=20privileged.=20=20If=20you=20ar=
e=20not=20the=20intended=20recipient,=20please=20delete=20the=20message=20=
and=20any=20attachments=20and=20notify=20the=20sender.=20=20This=20email=20=
is=20not=20intended=20to=20create=20legally=20binding=20commitments=20on=20=
behalf=20of=20FDM=20Group=20Plc,=20nor=20do=20its=20contents=20reflect=20t=
he=20corporate=20views=20or=20policies=20of=20FDM.=20=20Any=20unauthorised=
=20disclosure,=20use=20or=20dissemination,=20either=20whole=20or=20partial=
,=20is=20prohibited.=20FDM=20Group=20Plc=20is=20a=20private=20limited=20co=
mpany=20registered=20in=20England=20(Reg.=20No.=202542980).


________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star=20I=
nternet.=20The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________