Editors (forked off from 'Your Os Design')
Posted: Mon Jun 07, 2004 7:53 am
All started with
candy:> To be proper gnu software it needs to "do one thing and do it well"
curufir:> Care to explain how EMACS slipped through the net?
Candy:>
mystran:>
candy:> To be proper gnu software it needs to "do one thing and do it well"
curufir:> Care to explain how EMACS slipped through the net?
Candy:>
Curufir:> Nope. I refuse to believe it. It has it's own LISP dialect, little text mode games, command line access etc. Emacs is a shell masquerading as a code editorIt didn't even, it's just a really bad interpretation of the one thing
If you want to code well, you must have all your tools at handslength, so you must be able to compile, indent, test, run, debug the code within the editor. Since there are numerous instances of bugs where you want to rip your hear out, even the doctor is appropriate. It's just not what we'd expect from a code editor.
I personally would try, given the current state of computers, to make a streamcompiler, that you can send new-stream commands, so that it is constantly active & loaded. Then, call it from the user agent when a user leaves a piece of code (in the bg) to work on a different one, or when he explicitly wants it to be testcompiled. Then, when all the test compiles still work (indicated with red text in tabs), you can make a testrun because it's automatically linked to the new executable. Seems like a very productive way to code
mystran:>
While I use Vim instead of Emacs, I've actually considered the MzVim patch that's available to embed MzScheme into ViM. The usability of a code-editor depends critically on the ability to script the editor. Otherwise you end up doing the same thing again, and again, and again, and again. Better design is no excuse, since people have different needs. Hence, the only way to build a NON-bloated code-editor is to build the whole editor around the scripting language.