Re: Extension Language for a Text Editor

On Thu, 9 Oct 2003 06:09:29 +0900
Nikolai Weibull <[e-mail]> wrote:

> * Ryan Pavlik <[e-mail]> [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...

<snip>
> > 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 <[e-mail]>

"You'd be surprised what a platoon of heartless ninja lawyers
 can do in favor of a position." - 8BT