> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
PK> Yep. I'm looking forward to seeing what Nick comes up with.
Here's the package documentation that I have so far. I plan to expand
more on the later sections. I'm also willing to package up what code
I have and send that along, but I d
Andy Piper writes:
> > Yes but it's too trivial to implement as something separate from
> > Nick's JUCI. It should be included in it.
>
> I think this is a great idea! Did I miss the post about JUCI? I presume this
> does some sort of reflected invocation scheme so that Emacs looks like a
>
> Yes but it's too trivial to implement as something separate from
> Nick's JUCI. It should be included in it.
I think this is a great idea! Did I miss the post about JUCI? I presume this
does some sort of reflected invocation scheme so that Emacs looks like a
Java class to the Java side and vice
Hi!
Nick Sieger wrote:
[...]
> Maybe once the next generation of semantic is available we'll be able
> to do the entire refactoring engine in elisp, but until then, I think
> letting Java drive the control flow is OK as long as it can query
> Emacs for file/buffer info and let Emacs do the textual
> "GB" == Graham Bennett <[EMAIL PROTECTED]> writes:
[...]
GB> As for the JDEE <-> Java interfacing issue, it's quite a difficult
GB> one. The approach I took was drawn from the Transmogrify way of
GB> doing it - all the logic was on the Java side and there was an
GB> interface to get basic
Nascif Abousalh-Neto writes:
> Hi Paul,
> I think that in the case of Transmogrify we didn't have much choice.
> We wanted to interface with an engine and an interface that was already
> defined, so we could not change the control flow to use queues and even
> handlers. Maybe an adaptatio
Title: RE: Java -> elisp communication (was RE: BanInfo wizard anyone?)
Hi Paul,
I think that in the case of Transmogrify we didn't have much choice. We wanted to interface with an engine and an interface that was already defined, so we could not change the control flow to us
Nick Sieger writes:
> > From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, December 09, 2002 11:46 AM
> > To: Nick Sieger; Galen Boyer; [EMAIL PROTECTED]
> > Cc: Graham Bennett
> > Subject: Java -> elisp communication (was RE: BanIn
Nick Sieger writes:
>
> One small questions for you: How often do you upgrade beanshell versions, and what
>kind of considerations need to be taken into account before upgrading? I grabbed a
>recent version (1.2.7) of the beanshell and started developing against it rather than
>the versi
On Mon, Dec 09, 2002 at 01:50:59PM -0600, Nick Sieger wrote:
[ snip ]
> That's a valid point. When I examined the three sourceforge-based
> java refactoring tools available (JRefactory, Transmogrify and
> Freefactor) I liked the way Transmogrify was designed the best (but
> maybe I didn't look c
> From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 09, 2002 11:46 AM
> To: Nick Sieger; Galen Boyer; [EMAIL PROTECTED]
> Cc: Graham Bennett
> Subject: Java -> elisp communication (was RE: BanInfo wizard anyone?)
>
>
> Hi Nick,
>
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 07, 2002 8:45 AM
> To: Nick Sieger
> Cc: [EMAIL PROTECTED]
> Subject: RE: BanInfo wizard anyone?
> > Well, I didn't, but the beanshell is still directly
> involved. Elisp
> > s
Title: Java -> elisp communication (was RE: BanInfo wizard anyone?)
Hi Nick,
> > >> The translation layer could handle things like the java method
> > >> signature returning, say, a hashmap. The layer could have a
> > >> hashmap to alist conv
Nick Sieger writes:
> > >> The translation layer could handle things like the java method
> > >> signature returning, say, a hashmap. The layer could have a
> > >> hashmap to alist converter.
> > >
> > > I've actually got a working prototype of a generic
> > > interface/translation layer th
> >> The translation layer could handle things like the java method
> >> signature returning, say, a hashmap. The layer could have a
> >> hashmap to alist converter.
> >
> > I've actually got a working prototype of a generic
> > interface/translation layer that does just that. For now, I'm
> > c
On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote:
>
>> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Galen
>> Boyer Sent: Friday, December 06, 2002 8:45 AM To:
>> [EMAIL PROTECTED] Subject: Re: BanInfo wizard anyone?
[...]
>> The translation layer could handle
> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Galen Boyer
> Sent: Friday, December 06, 2002 8:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: BanInfo wizard anyone?
>
>
> On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote:
> > Another idea would be to add options to the jd
On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote:
> Another idea would be to add options to the jde-jeval
> function or new commands to
>
> * evaluate a bsh expression (e.g., a script invocation)
> and insert the result in a new Java source buffer
>
> * evaluate a bsh expression and insert the
Paul Kinnucan writes:
> Hi Christian,
>
> The basic trick to integrating a bsh script with the
> JDEE is to have the script write a Lisp form to
> standard out and then invoke the script via the JDEE's
> jde-eval function. The jde-eval function sends
> an arbitrary beanshell expresion via
Hi Christian,
The basic trick to integrating a bsh script with the
JDEE is to have the script write a Lisp form to
standard out and then invoke the script via the JDEE's
jde-eval function. The jde-eval function sends
an arbitrary beanshell expresion via standard I/O
to the beanshell and then eval
20 matches
Mail list logo