Re: Re : Re : [Chicken-users] Scheme (LISP) editing

[Peter Keller]

On Fri, Mar 02, 2007 at 02:48:48PM -0700, Shawn Rutledge wrote:
> I was hoping the same words would often reoccur on the display at the
> same time.  There would be a caching scheme, LRU or some such.  Just
> an idea, not sure if it's really better or not.

First off, noone would probably care if you rebind the texture for
every letter, it isn't like there is a bad speed penalty for such small
textures--especially for human reading speeds.

Second, you could make one big texture will all of the letters on it,
and use sub coordinates to pick the letters out as you render them.
Depending on the resolution you want, some cards might not be able to
load the texture, but these days, a 256x256 texture is probably more
than enough. Unicode might be more difficult, but just load more font
pages for what font you'd like to use.

Third, if you wanted individual textures per letter, then you could
sort the letters by frequency, load the first texture and draw all the
letters in the right places on the screen, then bind the next texture.

Seeing on how this is just text that a human reads, and that premature
optimization is the root of all evil, I'd say do option one.

Also, since you have the full bore of a 3d lighted texture mapping
engine behind you, the IDE could be something fantasical to behold. Like
undo buffers could go "into" the screen towards some vanishing point
and you can select your mouse on undo regions to undo certain things
whenver. It'd be sort of a visualization of vim's undo stacks behind
the text, all dimmed down until you need to see it.

Next idea. Ever see the dock on the new macosx? Suppose you have some
code like this:

file1.scm:
(define foobar (thingy 1 2 3))

file2.scm:
(define thingy (x y z) (+ x y z))

Then when editing file1.scm, if you drag your mouse over "foobar"
in context (hell, might as well use chords on the keyboard and add a
stroke interface), then the text all pushes to the sides (in a nice
fluid manner) and the definition for (only) "thingy" fades in enditable
form). You could then edit the definition of thingy (with all aspects of
the editor available to you here), hit the "back" button or whatever,
and go back to the original place you were. It's be like mixing ctags
and hyperlinks. Debugging could be the same deal, "drilling" down into
variables and stack frames and structures with hyperlink-like mouse
clicks would make debugging stuff very awesome and fast.

Then, if you'd like, you can save the entire drill down session as a
virtual workspace on some big texture and move to something else.... the
posibilities are endless. You'd make eclipse look like ed.

Also, the one awesome thing about writing a scheme editor that can do
all of this is that scheme is already in the ast form. You don't really
have to write a serious parser to understand and catagorize everything
like you do for java or C++. Doing stuff like refactoring on the fly in
those languages is painful. In scheme, it could be much easier. You just
walk the source and fix it in place. Parse errors can just be corrected
to the next valid form and you'd probably get it right 99% of the time.

Then, if someone ever invents a fundamental debugging specification format
for scheme (think dwarf2 or stabs), then your debugger/editor can load
it and present all sorts of awesome visual markup information for you.

Highlighted scheme froms and bouncing parenthesis are so 1975. To bad
that all IDEs _even today_ still basically do that (except type popups
and context completion showed up in the early 90's, but when you conthink
about it, it really only is an incremental evolution) and haven't even
really *began* to touch the code/debugging visualization realms that
only exist in programmer's heads.

If you make this, don't copy what is already done, make something
to behold!

-pete