Re: That "vision" thang...

Marcus Harnisch writes: 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 XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta