Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Fri, 16 Jul 2010 18:07:21 +0200
> 
> >   . The "relocatable allocator" which moves memory of allocated
> >     objects (such as the buffer text) when large chunks of memory are
> >     allocated or freed.  Also, allocation of memory off the pure
> >     space, during the build process.  These will probably need a
> >     custom new/delete implementations, and various C++ techniques such
> >     as smart pointers may need to be adjusted, or not used.
> 
> For this I would try to isolate the display manager's memory management
> from the rest of Emacs. As far as the display manager doesn't need to
> allocate or free objects created by Emacs, and vice-versa, it should
> work. Right?

How can a display engine has its memory management isolated, if it
needs to call Lisp primitives to access Lisp objects and operate on
them?  Just a random example: when you bump into a buffer position
that is covered by a text property or overlay, you need to call a
function that returns that property's value, which requires a call
such as

  prop = get_char_property_and_overlay (make_number (position->charpos),
                                        Qdisplay, object, &overlay);

The call to make_number here creates a Lisp object.
get_char_property_and_overlay is one of the few basic APIs the display
engine calls to find what are the text properties at a specific buffer
or string position.  Rewriting it (and other similar APIs that the
display engine needs to call to do its job) to somehow work around the
need to create Lisp objects and pass them around will lead to a
massive rewrite of most of Emacs, or at the very least to a large body
of code built on top of the current interfaces.

I don't see how you can bypass this issue without getting your job
much larger and harder, for no good reason.

In my experience, C++ shines when you need to maintain software and
want to be able to extend and refactor it without too much pain.  It
doesn't help you much when you start a new project from scratch.
Since you are talking about a throw-away project, I don't really see
any gains in C++; I do see a lot of obstacles that are in no way
directly relevant to your undertaking, so overcoming those obstacles
would be simply waste of time and effort.

> A random thought now about something that intrigues me: AFAIK the only
> purpose of dumping is to include into Emacs' executable the set of
> compiled Elisp code that is required to be usable.

I think it was primarily for faster startup, but that's something we
should ask Richard.

> I guess that the approach made sense when distributing Emacs as a
> single executable could be useful. But now hardly anyone installs
> Emacs without the extensive Elisp library and other auxiliary files,
> so the "self-contained functional Emacs executable" has little
> value. Of course I may be wrong when guessing this, but if it is
> right, wouldn't make more sense to dump all that Elisp bytecode to a
> single file that is loaded on startup? On exchange of a startup time
> just a bit larger, the simplification on other areas would be
> considerable.

Doesn't the XEmacs "portable dumper" works like that?

Anyway, dumping is the murkiest part of Emacs for me, and I try very
hard to stay away of it.  I'm happy enough that it works for me, and
hope it will never break on the platforms that are important for me.
I only know something about its perils because I was once involved in
making a standard C library dump-compatible.