Re: Extension Language for a Text Editor

* Ryan Pavlik <[e-mail]> [Oct, 09 2003 09:10]:
[stuff about Emacs and 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.
Yes, that, as I see it, is Emacs biggest win.  The big problem I see
with Vim is that it hasn't undergone a major overhaul.  It is basically
Emacs written in C now.  Vim is, in my opinion, probably the best editor
that exists right now.  It is, however, going to reach a point where
adding new features will demand some sort of rewrite.  With Emacs,
things like these are easy to alter.  Anyway, Vim is extensible, it is,
however, not _changable_.  By that I mean that, if you want to change
the way folding works, you must rewrite the core of Vim.  And, as Bram
pointed out in some interview, that means altering basically every file
in the Vim distribution.  To Vim's salvation comes the ability to easily
define new syntax definitions and indentation definitions, which one has
to agree, are a lot easier to create and alter than with Emacs (Emacs
being perhaps more powerful though).
[stuff about Ruby libraries and such]
> Right.  They're there, people can write extensions that interface to
> the web, or whatever.
Yes, but I don't want an Operating System.  I guess, to a certain degree
the library you get helps you, but it can also detract you from the
central topic, namely editing text.
> 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.
Yeah, OK.  I see your point.  It is, however, very easy to alter to fit
your own needs.  Change some global variables and you can make it work
for almost anything.  I can't tell, but I'm guessing your code in Ruby
wouldn't allow for this?  I'm not trying to contract you, only point out
that Emacs extensions are, as oposed to Vim extensions, very flexible
and well thought out.  This does, of course, not mean that it can't be
done in Ruby.  I just get the feeling that Lisp excels at this.
[stuff about functional vs. OO being more well suited for editing text]
> 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. ;)
My real point was that having OO around doesn't really help either.  It
doesn't add anything.  Sure, you can make classes like Buffer and Window,
were is the real gain?  I have tried to envision some OO structure for
implementing Emacs like Major/Minor Modes and such, but I haven't been
able to come to any satisfactory results.  I mean, how is a Major Mode
an object?  Really?  I guess it has a syntax definition, a separate
keybinding mapping, an indentation callback, maybe something else?  I
just don't feel it adds anything though.  I am, of course open to
suggestions ;-).
> Right, tiny C core like emacs, everything higher-level in the language
> of choice.  Ruby is highly suited for this task.
Yeah, this is true.  Ruby would be well suited for this I do believe.
But note that Emacs C core isn't very small ;-)
> People could even write high-performance ruby extensions in C...
Yeah, this would be easy to do as well.  There is, of course, the
inherent risk of not being portable enough.  Vim supports this in a way,
and I have never seen it used to date.
[stuff about regular expressions]
> 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.
As useful?  Please, my dear sir, there has to be something better than
the way we describe regular expressions now.  At least for searching
text.  The syntax we have today for regular expressions is basically the
same, only extended, as that that Ken Thompson uses in his 1968 paper on
it.  Or that of _real_ regular expressions long before it.  And
remember, real regular expressions only have * (Kleene star) and no +.
There has to be a simpler syntax that can be useful for interactive text
search-and-replaces.  Look at Vim, Emacs, and Perl (and thus,
basically, Ruby)'s syntax.  They are all extensions of this, adding new
short cryptic ways of saying things that you often don't need, and if
you did you wouldn't want to do it that way anyway.  The real example of
how it has gotten out of hand is the overuse of backslash (\).  It is
everywhere.  having to move my hand to the upper right corner of my
keyboard all the time is a real pain.
Of course we'll have to see if I'm actually able to come up with
anything better.  It's probably not going to be as easy as I'd like to
suggest here.  However, look at the Perl 6 Apocalypse 5[1] to see one way
of moving away from cryptic (?:...) metasyntaxes.
> 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_.
Nah OK.  You've got a point.  But, as with most free software, this
one's for me ;-).  If anyone wants to tag along later on, fine.  But I
won't care if no one is interested, Emacs and Vim are fine editors.
Even notepad has its uses.  It can, for example, tell you if a file is
smaller or greater than 65535 bytes very easily ;-).
I have, perhaps, failed to describe the real winning here.  (Alas, I
realize I forgot to mention it.)  As you perhaps know, Vim, and most
other UNIX software, operate on a line-by-line basis.  This restriction
would not impede the command language I'm contemplating.  If you take a
look at the Sam editor[2], this is its main selling point, and this is
another one I want to include.
> > 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.
Nono, they don't do string escapes.  \n in a regex (//) means match a
newline, not substitute this for 0x0a.  So, you don't have to quote it
with an extra backslash to get that meaning.  Eh, maybe I'm not making
myself clear.  See, in Emacs, you have to write it as
	"\\n"
since, otherwise you get the mentioned effect.  This may be OK most of
the time, but it has implications.  Also, if you want to match a word
boundary in Emacs you'll have to write
	"\\<"
and to match a backslash itself:
	"\\\\"
which is horrendous.  In a Ruby regex, /\\/ suffices.
	nikolai

[1] http://www.perl.com/pub/a/2002/06/04/apo5.html
[2] http://plan9.bell-labs.com/sys/doc/sam/sam.html or as PostScript:
    http://plan9.bell-labs.com/sys/doc/sam/sam.ps

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}