Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

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

For this especific example, I see no problem. The display backend will
obtain `prop' as you say, gather the needed information and dispose
`prop' immediately, following whatever Emacs protocol is required.

On this aspect I don't foresee serious problems (speaking from my
ignorance.) Maybe some data needs to be duplicated on both memory
spaces, but that's just an annoyance.

[snip]

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

I want to use Qt. The easiest way for that is to use C++. There are Qt
bindings for several languages (Python included) but there are no Emacs
bindings for them (and if you see potential low-level compatibility
problems with C++, what can we expect from Python?) I'm thinking on the
possibility of using a private language of mine, which is very C/C++
friendly and much more productive than C++. This means less work and
more fun for me, but it makes very difficult for anybody else to look
into the project. IMO C++ is the only sensible option. I have 15 years
of experience with it and understand the global implications, although
probably you are right and I'm missing some important details specific
to the Emacs implementation, but can't see how using other language with
available Qt bindings could improve things.

[snip]