Re: Emacs and Gnome Canvas

[Miles Bader <miles@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:
>   . Jan says we need to maintain a GtkTextBuffer object for every
>     buffer we have in Emacs.  Does that mean buffer text will be held
>     twice in memory, once as it is today, the other as GtkTextBuffer?
>     What will that do to Emacs's ability to visit very large files?
>     Even today there's demand to be able to visit files that are 1GB
>     or 2GB in size.  Doubling that would be a serious impediment.

... and it's not just memory -- a serious problem with many
"pre-rendered" text display implementations (e.g., most web-browsers) is
that there's a _massive_ delay/slowdown when displaying a huge
documents.

[Most people don't display huge documents (especially in web-browsers
etc), of course, so these implementations work OK for "typical" use.
But AFAICT, it's definitely an important goal of Emacs to handle more
extreme cases too.]

> Or maybe you are thinking about _replacing_ buffer text with
> GtkTextBuffer?  That would mean you'd need to redesign buffer
> management code.

and pretty much rewrite or toss out a lot of lisp code that uses any but
the most basic features.

I think code re-use and sharing commonly used libraries is a very good
thing, and should be done as often as practical -- but I just don't
think it's practical in the case of Emacs buffers/high-level-redisplay.
Emacs is simply too different.

[If someone wanted to _rewrite_ emacs from scratch, not maintaining
compatibility with the vast majority of legacy code, this would likely
be a good route to follow of course (though even in that case, there's
always the possibility that implementations like GtkTextBuffer are
simply not good enough to handle more hardcore use).]

Of course, using a lower-level interface, e.g., GTK/cairo/whatever as a
drawing library (which Emacs redisplay would call to display), instead
of e.g. X, would probably be practical though, and might even be fairly
easy to do given that the drawing layer already has an abstract
interface because of the various backends already supported.

-Miles

-- 
Once, adj. Enough.