From: Eli Zaretskii <eliz@gnu.org>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs and Gnome Canvas
Date: Thu, 15 Jul 2010 18:14:36 +0300 [thread overview]
Message-ID: <83vd8gg4kj.fsf@gnu.org> (raw)
In-Reply-To: <87fwzkbzg8.fsf@telefonica.net>
> 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.
next prev parent reply other threads:[~2010-07-15 15:14 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 19:02 Emacs, QT and Cairo Was: Re: Efforts to attract more users? Stephen Eilert
2010-07-13 19:29 ` Chong Yidong
2010-07-13 19:51 ` Chad Brown
2010-07-13 20:48 ` Jan Djärv
2010-07-13 22:30 ` Emacs, QT and Cairo Chad Brown
2010-07-14 1:39 ` Stephen J. Turnbull
2010-07-14 2:32 ` Óscar Fuentes
2010-07-14 7:29 ` Eli Zaretskii
2010-07-14 18:37 ` Chad Brown
2010-07-14 20:45 ` Eli Zaretskii
2010-07-14 21:24 ` Óscar Fuentes
2010-07-15 6:55 ` Emacs and Gnome Canvas (was: Emacs, QT and Cairo) Eli Zaretskii
2010-07-15 7:46 ` Emacs and Gnome Canvas Jan Djärv
2010-07-15 7:53 ` Jan Djärv
2010-07-15 8:36 ` joakim
2010-07-15 8:40 ` Eli Zaretskii
2010-07-15 8:50 ` Jan Djärv
2010-07-15 8:38 ` Eli Zaretskii
2010-07-15 8:48 ` Jan Djärv
2010-07-15 8:59 ` Eli Zaretskii
2010-07-15 9:29 ` Jan Djärv
2010-07-15 10:24 ` Eli Zaretskii
2010-07-15 10:54 ` Jan Djärv
2010-07-15 12:27 ` Eli Zaretskii
2010-07-15 14:18 ` Óscar Fuentes
2010-07-15 15:14 ` Eli Zaretskii [this message]
2010-07-16 6:33 ` Miles Bader
2010-07-15 16:00 ` Chong Yidong
2010-07-15 16:27 ` Óscar Fuentes
2010-07-15 17:06 ` Eli Zaretskii
2010-07-15 17:48 ` Óscar Fuentes
2010-07-15 18:06 ` Eli Zaretskii
2010-07-15 21:27 ` Óscar Fuentes
2010-07-16 8:17 ` Eli Zaretskii
2010-07-16 14:24 ` Óscar Fuentes
2010-07-16 15:19 ` Eli Zaretskii
2010-07-16 16:07 ` Óscar Fuentes
2010-07-16 18:43 ` Eli Zaretskii
2010-07-16 21:21 ` Óscar Fuentes
2010-07-16 23:44 ` Chad Brown
2010-07-17 0:08 ` Óscar Fuentes
2010-07-17 7:57 ` Eli Zaretskii
2010-07-17 8:34 ` Andreas Schwab
2010-07-17 9:10 ` Eli Zaretskii
2010-07-17 9:40 ` Andreas Schwab
2010-07-17 10:23 ` Eli Zaretskii
2010-07-17 13:49 ` Óscar Fuentes
2010-07-17 7:27 ` Eli Zaretskii
2010-07-17 13:42 ` Óscar Fuentes
2010-07-17 15:27 ` Eli Zaretskii
2010-07-17 21:53 ` Óscar Fuentes
2010-07-18 1:42 ` Miles Bader
2010-07-18 2:45 ` Óscar Fuentes
2010-07-18 8:06 ` Chad Brown
2010-07-18 14:43 ` Óscar Fuentes
2010-07-21 8:34 ` Stefan Monnier
2010-07-22 14:26 ` Stefan Monnier
2010-07-15 17:22 ` Chong Yidong
2010-07-15 18:02 ` Óscar Fuentes
2010-07-15 22:10 ` Stephen Eilert
2010-07-16 7:52 ` Eli Zaretskii
2010-07-16 2:14 ` YAMAMOTO Mitsuharu
2010-07-16 7:33 ` Jan Djärv
2010-07-16 9:52 ` Eli Zaretskii
2010-07-16 10:15 ` YAMAMOTO Mitsuharu
2010-07-16 10:39 ` Eli Zaretskii
2010-07-16 12:42 ` Jan Djärv
2010-07-17 3:50 ` YAMAMOTO Mitsuharu
2010-07-17 8:33 ` Jan Djärv
2010-07-17 8:38 ` YAMAMOTO Mitsuharu
2010-07-17 9:18 ` Jan Djärv
2010-07-17 9:25 ` YAMAMOTO Mitsuharu
2010-07-17 10:26 ` Jan Djärv
2010-07-18 3:51 ` YAMAMOTO Mitsuharu
2010-07-18 7:10 ` Jan Djärv
2010-07-18 7:45 ` YAMAMOTO Mitsuharu
2010-07-18 9:06 ` Jan Djärv
2010-07-19 0:50 ` YAMAMOTO Mitsuharu
2010-07-17 1:00 ` YAMAMOTO Mitsuharu
2010-07-17 1:40 ` YAMAMOTO Mitsuharu
2010-07-17 8:04 ` Eli Zaretskii
2010-07-17 8:25 ` YAMAMOTO Mitsuharu
2010-07-16 12:21 ` Jan Djärv
2010-07-16 10:01 ` YAMAMOTO Mitsuharu
2010-07-16 12:26 ` Jan Djärv
2010-07-16 14:05 ` Davis Herring
2010-07-16 17:38 ` Jan Djärv
2010-07-17 1:12 ` YAMAMOTO Mitsuharu
2010-07-17 7:14 ` Eli Zaretskii
2010-07-17 7:31 ` YAMAMOTO Mitsuharu
2010-07-17 8:12 ` Eli Zaretskii
2010-07-17 8:32 ` YAMAMOTO Mitsuharu
2010-07-15 14:24 ` Jan Djärv
2010-07-15 14:35 ` Eli Zaretskii
2010-07-15 15:16 ` Jan Djärv
2010-07-15 15:20 ` Eli Zaretskii
2010-07-15 17:14 ` Jan Djärv
2010-07-15 9:20 ` Andy Wingo
2010-07-15 18:41 ` Emacs and Gnome Canvas (was: Emacs, QT and Cairo) Dirk-Jan C. Binnema
2010-07-15 21:51 ` Emacs and Gnome Canvas Óscar Fuentes
2010-07-15 22:21 ` Bruce Stephens
2010-07-27 21:24 ` Emacs, QT and Cairo Stefan Monnier
2010-07-27 21:36 ` Chad Brown
2010-07-28 3:05 ` Eli Zaretskii
2010-07-14 8:59 ` Emacs, QT and Cairo Was: Re: Efforts to attract more users? YAMAMOTO Mitsuharu
2010-07-14 9:41 ` Emacs, QT and Cairo David Engster
2010-07-14 9:56 ` Jan Djärv
2010-07-14 13:50 ` Drew Adams
2010-07-14 14:14 ` David Engster
2010-07-14 14:28 ` joakim
2010-07-14 15:41 ` Emacs, QT and Cairo Was: Re: Efforts to attract more users? Chong Yidong
2010-07-14 16:17 ` joakim
2010-07-14 18:04 ` Jan Djärv
2010-07-15 23:15 ` Andrew W. Nosenko
2010-07-16 7:41 ` Jan Djärv
2010-07-16 10:24 ` Andrew W. Nosenko
2010-07-16 12:36 ` Jan Djärv
-- strict thread matches above, loose matches on Subject: below --
2010-07-17 19:02 Emacs and Gnome Canvas grischka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83vd8gg4kj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.