"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
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.
That was my first impression when I saw that.
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
This is an excellent example of where we could benefit from using a
toolkit. One of our users complains, we identify GtkTextView and can
tap a much larger pool people to look at the issue than just XEmacs
There are several misfeatures I've identified already. [...]
Many many questions remain. [...]
Doe anyone know a GTK expert? Perhaps one of the gedit developers? I
suspect that gedit was the driving force behind all these features. It
has grown into more than a Notepad-for-Gnome.
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 was pointing to that merely because I found the similarity in
concept a good way to demonstrate that toolkits have moved on quite a
bit since our first attempt to integrate GTK. Multiline text editing
has become more than what we find in HTML.
Not knowing much about either XEmacs internals nor GTK, I would
probably start with desktop integration features before tackling
buffer rendering. In fact I guess this would be the last thing to
convert simply because it does work smoothly on the platforms I use.
XEmacs-Beta mailing list