[Fluxus] extending the editor

[Dave Griffiths]

Hi Jeff,

Sorry, wrote this rambling email yesterday so repeating a lot of what
others have said...

> Hi,
>    I've been working a bit on beefing up my live-coding chops using
> various livenoisetools and fluxus.  Great stuff and lots of fun.  I have
> to admit though, that the editor frustrates me often.  I'm a vim hacker,
> and I feel crippled without having mechanisms to move around the code in
> terms of s-expressions, search and replace with regexps etc.

You're not the only one - this is definitely an area in need of work.

> So my first question is, what's the easiest way to use an external editor
> with fluxus?

DrScheme is usable with fluxus, and I've done a lot of fluxus development
with it. Just put (require fluxus-015/drflux) at the top of a normal
fluxus script and you can edit and run it inside DrScheme.

There are stability issues with doing this at the moment - certain things
cause crashes, some things look like garbage collection problems I need to
look into, others are due to the way that opengl is set up in DrScheme.

There is also a way to do similar things with emacs as well, but I've
never tried that:
http://lists.pawfal.org/htdig.cgi/fluxus-pawfal.org/2007-November/001131.html

> The editor is very cool in other respects though, so in the long run I'd
> like to stay inside the fluxus editor rather than just code in vim and
> send it over.  So, I wanted to throw an idea/proposal out there.  How
> about taking the keyboard (and maybe also mouse) input from glut and
> sending it to a scheme instance that manages the editor?  (Not sure if
> it should be the same one as is used for graphics or not...)  In a weekend
> we could setup a simple command scheme that lets us start building up a
> library of editor functions that can be mapped to sets of key-commands.
> I guess it's a new-school, live-coding emacs.  (Maybe humorous from a
> vimmer...)  I also think it would be really cool to map commands to keys
> on the fly.  If using vim like modes, this could add a new dimension to
> live coding...

Interesting idea - a lot of this is already set up, the scheme side gets
all the key presses so you can query them inside fluxus scripts. I think
what you are proposing makes a lot more sense than the way it's currently
working. I was hoping for finding a way of using another editor as library
somehow, but I don't think that's possible.

>    How does this sound?  The only part I don't know about yet is how to
> connect up C++ functions to scheme, but I imagine you can either use
> their FFI or C interface.

The main graphics code is done via the C interface, but is separated from
the editor, which has very limited access to the rest of fluxus. I've
started doing more editor code in scheme - the auto formatting is, by
calling into the interpreter and getting out the result. I'm in favour of
moving much more into scheme in this way - until the C++ code just passes
key presses in and nothing more.

Something interesting I figured out from talking to the PLT folks is that
the needs of livecoding are suitably different to general programming and
teaching (the emphasis of DrScheme) that maybe warrant a separate
environment. This came up while discussing the way that during livecoding
you need to evaluate into the same interpreter repeatedly, whereas in most
other cases of programming you want to start afresh each time you press
F5.

As I said, I do use DrScheme a lot for more normal development - the only
thing that's not too good is it's memory footprint, the current fluxus
editor running with mzscheme uses much less.

cheers,

dave