Re: Emacs and Gnome Canvas

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 16:18:47 +0200
> 
> From your discussion it seems that the only serious "problem" with Emacs
> and Gnome's canvas (or any other canvas) is coupling the Emacs display
> system with it.

I wish!  That was just the first thing on my mind after reading that
white paper.  The tip of the iceberg, so to say.  There are other
"lesser" considerations, that are nevertheless quite serious and
should be considered up front.

I already mentioned the fact that input processing and the whole logic
of the Emacs idle loop will need to be reconsidered and modified.  A
few more examples of the issues that need to be considered:

  . We represent characters as a super-set of Unicode, using upper
    planes for characters that are not unified (for cultural reasons)
    and eight-bit raw bytes.  I'm quite sure Canvas can deal with
    UTF-8 encoded characters, but what will it do with codepoints that
    extend Unicode?  How to tell it which fonts to use for them and
    how to interpret them in general?

  . Display of composed characters.  Emacs specifies compositions via
    either (a) text properties or (b) char-tables.  I'm quite sure
    that display of composed character is supported by Canvas, but how
    to we communicate the above two types of specifications from Emacs
    to Canvas?

  . 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.

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

And those are just examples.

> My plan is radical: bypass the current Emacs display system
> and implement a new one on top of the canvas. This would be purely
> event-driven, hopefully with very little special cases for the platforms
> where Emacs runs, and substantially simpler because the canvas would
> take care of the low level chores.
> 
> On the long term, this could allow to remove the GUI code from the current
> display system and left the tty code alone.
> 
> If the display system is decoupled from the buffer-handling code, the
> high-level event system (Elisp hooks, etc) and the rest of Emacs in
> general, it could be doable with a reasonable amount of work for a
> single developer. Maybe I'm being too optimistic.

I hope you are not overly optimistic, and I wish you success.  I
really do.  But because there's no formal specification of the Emacs
display system, you have no exhaustive list of requirements which you
will need to implement.  May I suggest to begin with some process of
requirements capture?  That would at least allow to produce some kind
of plan, identify the possible difficulties, and outline ways of
overcoming them.  Note that doing what you want will touch not only
the display, but also all of the basic objects and probably change
quite a lot the whole top-level architecture.  That kind of open heart
surgery is not recommended without at least some prior analysis.  And
since no one knows enough of Emacs internals in enough detail, no
single person can do all that and succeed.

Just to put things in perspective: the integration of bidi reordering
into the display engine was intensively discussed over a period of 2
years, with active participation of Gerd Möllmann, the architect and
implementor of the current display code.  At least 2 other designs
were proposed (and one of them was even implemented) and rejected,
before the current design was agreed upon.  Needless to say, the bidi
support is nowhere near the redesign you are proposing, in terms of
complexity and overall effect on parts of Emacs outside display
proper.

I'm not trying to spook you off, and I really welcome an attempt to
revamp the display engine.  I'm just saying that without some minimal
analysis of requirements and possible high-level design decisions,
this project will have very small chance of delivering.