From: Ryan Pavlik Date: 2003-10-09T07:03:31+09:00 Subject: Re: Extension Language for a Text Editor On Thu, 9 Oct 2003 06:09:29 +0900 Nikolai Weibull wrote: > * Ryan Pavlik [Oct, 08 2003 22:30]: > > YES. I've been wanting "erubs" (Editor for Ruby Scripts ;-) for > > awhile; something like emacs, but s/lisp/ruby. Same design > > otherwise. > hehe, that won't be the name, but yeah, that's in a sense what I want. > Except s/Emacs/Vim/ ;-). Well, whichever, just be aware that emacs is designed as an extensible editor, and vim is not, even though such things have crept in with varying degrees of usefulness. > > Well, the main thing is that ruby has a lot of very convenient pattern > > and text matching functionality, and a boatload of extensions. And > > it's a very easy language, so anyone can pick it up and start > > extending the editor, unlike emacs, where fewer brave the waters. > Well, no dependencies on Ruby extensions would be necesarry, but I > guess, since they exist, they could be used. Right. They're there, people can write extensions that interface to the web, or whatever. > > This was a few simple lines of ruby. Not counting comments, it's 44 > > lines of lisp that don't quite work perfectly. > Could you provide the code? I'd love to see the comparison. See http://ogmo.mephle.org/tabular-alignment.org for the Lisp version. The ruby one I deleted, as it was pretty simple to reproduce, I'm sure someoone can whip up an example. > > As much as I love lisp, I can't really think of things that would be > > easier to in any of the above scheme flavors that wouldn't be easier > > in ruby. > OK. The way I see it, Ruby is OO-programming personified. LISP is, > well, functional? programming personified. Anyway, I have gotten the > feeling that it's generally easier to think in terms of functional, not > OO, when editing text. I mean, what do tho OO constructs really > add? I don't really find that. I don't think functional programming is any easier for editor-related tasks. I'm not even sure how you would come up with such an assumption. ;) > > Ruby certainly allows this. It's extremely trivial to extend and use > > Ruby in C. They go hand-in-hand. Plus there are existing GUI > > packages you could interface to if you wanted to provide UI handling > > in ruby without a lot of work. > Ah, I think you misunderstood the question. Or I'm misunderstanding the > answer ;-). I want the C core to be as small as possible, leaving the > most possible flexibility using the extension language. And I don't > generally see the need for GUI extensions and such. Right, tiny C core like emacs, everything higher-level in the language of choice. Ruby is highly suited for this task. People could even write high-performance ruby extensions in C... > > However, that's not to say you can't make your own matching format. > > I'm not sure what you have in mind, but there are a number of ways to > > bend the syntax to integrate such things. > Yeah, but that's just the thing. This is one of the real selling > points, if you will ;-). Oh well, I guess one can always do some Well, to be blunt, whatever you come up with won't be as popular or useful as the existing regular expressions, just because they'll be a nonstandard replacement of something already very common. PCRE regexps are extremely flexible and well-known. That isn't to say people won't use them, especially if they're simpler, but it probably won't be the main selling point of your editor to _other people_. > MyRegex.new(string) > but then you wind up with the string interpolation problems (\n and > friends). :-( I'm not sure how that's a problem. The same applies to // regexps. They're just basically strings, except stored in a different type of object with a few flags. hth, -- Ryan Pavlik "You'd be surprised what a platoon of heartless ninja lawyers can do in favor of a position." - 8BT