different string representation (buffer gap)

[manders2k]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7xr7xbfjbe.fsf at ruckus.brouhaha.com>...
> You can do some of that with the array module, but Python's regexp 
> library doesn't give any way to search backwards for a regexp, so that's
> another problem you'll face trying to write an editor in Python.

Yeah, I have a feeling that it might be easier to code up the buffer
in C/C++, and embed it in the interpreter.  I'm not sure how much of a
performance bottleneck having this very low-level component written in
python will be on modern machines; probably not such a big deal. 
Writing a buffer class and fiddling with pointers and whatnot actually
sounds easier to do in C++ than in emulating this style of thing in
Python (then again, I'm a heck of a lot more comfortable with C++ than
Python at this point, so that might not speak to the difficulty of the
task).

What I guess I wish were the case is that I could implement the
"string interface" on my BufferGap, so that everywhere that Python (at
the C API level) expects a string, a BufferGap could be used instead. 
That way, all the libraries that inspect and operate on strings would
work transparently, without having to be recoded (copy / paste, end up
with a lot of mostly identical, redundant code) to operate on this
other string representation.  Maybe this just isn't possible with the
current C-Python implementation.  I suspect it would be with many
possible C++-Python implementations, but we don't have one of those
lying around so...

I'm pretty sure that for modest size buffers (even a megabyte of
text), copying the contents of the buffer into a python-string
representation before operating on it with python-libraries would be
transparently fast.  It just seems...wasteful, and potentially very
bad news if someone ever tried to do a regex search on a buffer that
occupied more than half of the physical memory of the machine or
somesuch.