[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs and Gnome Canvas
From: |
Eli Zaretskii |
Subject: |
Re: Emacs and Gnome Canvas |
Date: |
Sat, 17 Jul 2010 10:27:32 +0300 |
> From: Óscar Fuentes <address@hidden>
> Date: Fri, 16 Jul 2010 23:21:19 +0200
>
> > 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.
`prop' is a Lisp object. (So are `object' and `overlay'.) Lisp
objects don't need to be disposed of, they are garbage-collected by
the GC. But GC, too, might need to be examined for possible
incompatibilities with C++ memory management.
As another example, consider constructing the mode line. The
mode-line spec is nowadays full of Lisp strings and text properties,
and the code which handles that in the current engine calls
make_string quite a lot. make_string creates a Lisp string and
triggers all kinds of behind-the-scenes reshuffling of string and
buffer text that a normal C/C++ program does not expect.
Anyway, what I tried to show was that manipulating Lisp objects is an
integral part of any Emacs display engine; you cannot hope to sidestep
it. Therefore, it is important to have a plan and infrastructure for
dealing with it, because otherwise you will need to change your
implementation each time you bump into an example you didn't think
about.
> I want to use Qt.
What for?
- Re: Emacs and Gnome Canvas, (continued)
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16
- Re: Emacs and Gnome Canvas, Chad Brown, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/17
- Re: Emacs and Gnome Canvas, Andreas Schwab, 2010/07/17
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/17
- Re: Emacs and Gnome Canvas, Andreas Schwab, 2010/07/17
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/17
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/17
- Re: Emacs and Gnome Canvas,
Eli Zaretskii <=
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/17
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/17
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/17
- Re: Emacs and Gnome Canvas, Miles Bader, 2010/07/17
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/17
- Re: Emacs and Gnome Canvas, Chad Brown, 2010/07/18
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/18
- Re: Emacs and Gnome Canvas, Stefan Monnier, 2010/07/21
- Re: Emacs and Gnome Canvas, Stefan Monnier, 2010/07/22
- Re: Emacs and Gnome Canvas, Chong Yidong, 2010/07/15