Hi I'm keen to see where this goes. I think if it works well for mg, it might be interesting to see if tmux could benefit from something similar as well, although Scheme would be far from my first choice of language.
I don't think any of the languages you mention are really good choices in any way except size, but I can't think of any others offhand, so if these are what we have to pick from then it might as well be Scheme. And at least it isn't Forth. On Wed, Jan 27, 2010 at 09:19:21AM -0500, Ted Unangst wrote: > On Sun, Jan 24, 2010 at 5:22 AM, Ted Unangst <ted.unan...@gmail.com> wrote: > > So one of mg's bugs is that it's not extensible. This doesn't > > normally bother me, because I use vi. But I decided to do something > > about it. A full lisp like emacs would be a little crazy, given the > > point is to have a small editor. But tinyscheme isn't too bad. So in > > it goes. > > Let me expand on this point a little more, and ignore the demo for now. > > mg has slowly grown a number of C implemented extensions, but that's > not a scalable future. I think a real extension language is needed to > *prevent* bloat. That's my justification for the feature. Picking > the language used is a process of elimination. We have a couple > choices, but if we're going to keep it light weight, we shouldn't burn > 2k lines on a parser. So our choices are basically lisp or forth. I > assert without proof that forth is the wrong choice. > > It probably wouldn't be hard to implement the core of a lisp > interpreter myself, but I think there's some benefit for trying to > keep the language used close to a standard instead of branching out on > our own. And the two standards are Common Lisp (huge!) or Scheme. I > don't know how much or accurately tinyscheme implements scheme, but at > least at a high level all the documentation I found seems to work. > > I don't think we should worry too much about making mg slow. emacs is > not an editor with lisp, by design it's a lisp environment that > happens to start a text editor by default. I think it's obvious when > you're crossing that line, and we simply don't have to. :) > > Now the released code is, as stated, too early to be considered a > serious proposal. And the web browser extension, well, I needed to > pick something that mg clearly could not do with the existing macro > feature just to make sure this was the right approach. Doesn't mean > we want to include it by default. > > vim has indeed backed itself into a corner. vimscript isn't really > good enough, so there's piles and piles of C code backing it. That's > what I'm trying to avoid. > > Anyway, I'll work on it a little more over time. I just wanted to > show what I've got for interested parties. More to come.
