Kurt & Kas,
What exactly is the issue with the shell vs. the mini? I see that
using Vim could make a difference, but what advantages does Vim have
that the mini doesn't provide? Clearly, the shell is more customizable
(and I used it before I upgraded mini to CVS v2) but the entire
process of memorizing the file paths (even with ../../ syntax) seems
like a huge waste of energy compared to the time it takes to find a
file with cmd+o opening the mini.
I, at least, can get along with cmd + to add shreds--the one thing
that would seem to just decimate this (in terms to maximum usability
livecoding grandeur) would be a file browser/code library for the mini
(possibly stored in XML format, like iTunes Library). This way, it
would be just a matter of tagging your code files (with tags relevant
to style/interface/content/public classes) and sporking them from a
browser. Um, probably lots of work, and I can't code without =>, but
for anyone wanting a fun activity a code library would be one more
unique aspect to livecoding with ChucK that couldn't be found in SC.
(mostly just daydreaming instead of working)
Andrew
On Thu, Sep 10, 2009 at 11:05 AM, Kassen
Kurt;
Those abandoned shell plans you mention sound awesome. I hope someday (maybe with more and more people live coding) the shell becomes a priority again.
I suspect that part of the issue is that many people who now start working/playing with chuck never saw a CLI before. For these people the mini will be a lot more easy to use than shell. If shell were to grow to "be all it could be" we'd have something like a miniture vi or EMACS on our hands. I'd love that, you would, probably a dozen or so other people would and I think many young students starting out with their first code and beeps would hide under the nearest couch.
I strongly suspect (but I have no proof) that most people will want icons, a mouse and so on, and really; the mini does work quite well.
What I would advocate for the future of interacting with running ChucK code would be having all of that controllable straight from the commandline, then make the mini use hooks to that (this is already what is going on and why we can update ChucK, recompile the mini, and expect it to work). From there on people could write extensions to editors like vi and EMACS or even borrow the Fluxus "scratchpad" (simple but it looks good...) and use what they like. I don't think that highlighting a certain block of text in the mini would need to be that different from navigating scope from the shell (as outlined in those rather old plans), the hard but there is making it work at all.
Unless I'm mistaken, the one way to get data into the shell (for example code) is to type it in there yourself. I don't think we can have other programs do this for us. To me that makes it a bit of a dead end. People like us will be so picky about what makes a good editor that even the few who would prefer this scenario wouldn't agree on it. Then again; I would actually like to be able to reconfigure parts of the mini using ChucK code and I do think that would be a nice idea so maybe I have no right to talk about what is and isn't sensible in this :-).
At least we have Spencer; all of Spencer's ideas on editing ChucK so far turned out to be good ones, I feel.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users