Marcus Harnisch writes:
Excuse my ignorance, but are you sure this is still true with recent
toolkit? All this looks quite flexible to me:
Flexible, maybe. The design looks to be an abstraction of Emacs
buffers and windows.
We'd have to actually start implementing to be sure. I would guess
that the TextWidget provides about 1/2 of insdel.c from the features
described there and a look at the APIs for the main components. But I
have no idea how it performs on a 1GB buffer, and I have no idea how
it performs in a buffer with 30000 GtkTextTags. I wonder if it can
keep up with a buffer that's being fed by a process, and so on.
There are several misfeatures I've identified already. For example, to
insert a glyph that is not part of the text, like a bookmark, you have
to change the buffer text! And there seems to be no way to query a
buffer to find out what GtkTextTags are present at any given index.
So we need to maintain both the GTK object and a Lisp object
corresponding to an extent, and make sure they stay in sync.
The design is clearly very different from an Emacs buffer; GtkTextIter
looks to be essentially useless at the Lisp level since it becomes
garbage every time the buffer is edited. Yet they say "most text
manipulation is accomplished with iterators".
Many many questions remain. Would we have *full* control over the
keymap? How about the mouse? How do these objects interact with
garbage collection? How much effort would it be to implement
truncate-lines? Invisible text? Atomic extents? How would it
interact with our I/O code? How about strings?
My guess is that it would actually be quite a bit *harder* to
implement Emacs buffers and windows using GtkTextBuffer and
GtkTextView than it is to implement Emacs windows using Xlib.
I'm not sure about that, of course, but I can tell for sure that a lot
of effort would be involved in using this as a basis for an XEmacs
window, and it's not obviously a win in terms of simplicity.
XEmacs-Beta mailing list