[Fluxus] Fluxus Editor

[Dave Griffiths]

Hi Jeff,

On Thu, 2008-09-04 at 18:00 +0200, Jeff Rose wrote:
> Some thoughts on moving to a more scheme based editor...
> 
> As someone mentioned earlier, PLT scheme comes with a fancy editor 
> framework, which could save us lots of time in creating a more full 
> featured editor inside Fluxus.  Using an editor-canvas% that displays a 
> text% object we can pretty quickly get support for pluggable commands 
> that work with keymaps and a host of additional editor like 
> functionality for understanding s-exps, search and replace, etc.
> 
> In order to use anything in scheme/gui though, where this stuff resides, 
> we have to run the whole app under mred, the GUI enabled runtime, rather 
> than mzscheme.  DrScheme itself is a mred application though, and the 
> existing drflux.ss is already moving in the right direction.  It takes 
> the input events from MrEd and forwards them to Fluxus, but it just uses 
> the DrScheme editor and doesn't involve the GLEditor or Repl that are 
> implemented in C++.
> 
> So, what I propose is that Fluxus itself move to becoming a mred 
> application, rather than a Glut based application.  The big question is 
> whether we want to re-implement the GLEditor and Repl classes in scheme, 
> or instead morph the C++ editor into being an editor-canvas and export 
> its interface to scheme.

I think going for a mred application for livecoding is the way forward -
but this could (should?) be a general purpose scheme livecoding IDE. I
say this as there seems no great reason to limit it to fluxus - it would
be great for using other scheme environments for livecoding, such as rsc
(Rohan Drape's supercollider bindings) and FrTime's animation.ss. I'd
really like something like this.

I'm not sure how we'd get the text over gl context thing working purely
using mred, and we'd probably have to take an active role in the gl
bindings for PLT, as there are some things I think we'd need to add -
but I met the developer of this a few months ago and he was really keen
to help out.

Right now though, I'd be wary of removing the option of having a small
mzscheme/glut setup until I'm convinced that using mred we can get a
similar memory footprint and cpu overhead. DrScheme is great, but it's
such a memory hog... 

cheers,

dave