If you want any hope of getting this feature
considered, you need to frame it much differently.
What I was really hoping was that there would be a way
to implement it as a module. Looks like it will be
(++premchai21), so all is well.
Perl isn't a text editor
No, it's a high-level language. I wasn't asking for
Perl to be a text editor. (If I were, I'd have been
asking for things like lowlevel keyboard access for
checking when the buckies are held down.) We have
Emacs already, and by the time Perl6 comes out we
hope to have Emacs 22, which should be well on the
way toward good enough to be considered as a text
editor.
I'm not sure what prompted you to think I wanted Perl
to be a text editor. Perhaps you saw "Emacs lisp" and
just couldn't get "text editor" out of your head. In
that case, let me just say that elisp is the language
I use second-most (after Perl) precisely because it is
the second-most-powerful language I know. It is, for
example, more powerful than Python for many purposes.
Buffers are a large part of the reason.
So maybe I should explain the power of buffers, and why
I want to implement them in Perl6. Anyone who has ever
programmed in elisp will already know most of this, but
I guess this is perlmonks.org, not gnu.emacs.gnus, so
here goes...
Buffers are like strings on steroids, except that that
doesn't do their flexibility and usefulness justice.
It's like saying "objects are structs on steroids".
Buffers are not just a place to display text. In
Emacs, display is a primary use of them, but even in
Emacs not all buffers are intended to ever be shown
to the user; various modules use them as workspaces
for holding various kinds of state. Why don't they
just use variables or arrays of variables? Because
those structures are not as powerful. It's the same
reason Perl programmers don't all store their paired
data in arrays of arrays instead of hashes: hashes
are more powerful.
What's so powerful about buffers? Well, in a word,
they don't just hold data, but a significant amount
of metadata as well. I'm not going to go into string
properties (partly because they're not really only
a feature of buffers; strings in elisp have them
too), but I will talk about markers. These are the
"string bookmarks" tye was talking about. Let's
say you have some stuff stored in a buffer. Now,
let's say you're working with it, and you've reached
a certain point, and you want to hold your place
there while you look at some other stuff. You set
a marker (or save-excursion, which amounts to
dynamically scoping the default marker (called point
in elisp -- a lousy name and one I wouldn't keep
when implementing this in Perl)), go look at the
other data, and come back. No big deal, if it's
just one, because there are other ways to do the
same thing -- if it's just one spot. But now let's
do something complex. Let's say, for example, that
we want to implement an XML parser. (Yeah, I know
it's been done in Perl5; it's been done in C and C++
too (think Gecko), but that doesn't mean a higher-level
feature can't make it easier.) So, you've got your
XML source in a buffer... now you want to create a
DOM out of it. That means matching up tags, right?
Heh, heh, heh. This is where buffers get really cool.
You pass through the buffer one time, setting a pair
of markers for each tag you encounter (at the beginning
and end of the tag), adding the tag to your array of
tags, along with references to your markers indicating
the tag's location. No need to worry about the data
between them and where it fits just yet, because your
markers point right there. Then you walk
your array matching up the start tags with the end
tags and putting references to them in a tree, and your
DOM is complete. The markers send you straight back
to the data. So far so good, but so far there are
other ways to do it...
Now, here's what's really cool: let's say the data
in the buffer changes; something is inserted (by, say,
the DOM stuff an an ECMA script). Your markers all
still point to the right places. Try *that* with a
string and pointers. Not possible -- which is why
parsers done in langauges without buffers end up
with horrible hacks like pulling bits and pieces of
the source out into little pieces as they parse it,
storing the bits in little strings, and attaching
those to the DOM tree.
As a result, they either have a complete duplicate
of all the data, or else they mangle and lose the
original source (what Gecko does) and have to try
to reconstruct it if it's needed again. Ick. If
it had been implemented in a language with buffers
and markers, things would have been much easier and
more sane.
You could argue that what I've just described is all
text-editing stuff, but in that case most of the major
applications in existence -- web browsers,
spreadsheets, databases (yes, buffers can hold binary
data), word processors, web servers, mail servers, ...
they're all text editors. Because they all handle
text. Lots of it.
Yes, there are programs you could write that would
derive small or no benefit from buffers. Photo
editors (a la Gimp) come to mind. There are also
programs that don't need hashes or objects, but
that doesn't stop Perl from giving us useful things.
I've only scratched the very surface of the usefulness
of buffers. They're at least as useful as objects or
hashes. For a full explanation, I refer you to the
Gnu Emacs Lisp Reference Manual. HTH.HAND.