From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Fri, 16 Jul 2010 23:21:19 +0200 Message-ID: <87zkxr6s34.fsf@telefonica.net> References: <4C3EBCDC.8050709@swipnet.se> <83d3upgmwj.fsf@gnu.org> <4C3ECB4C.6050208@swipnet.se> <83aaptgly1.fsf@gnu.org> <4C3ED4F9.4080603@swipnet.se> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <877hkwbth6.fsf@telefonica.net> <83pqyofzdg.fsf@gnu.org> <8739vkbpq5.fsf@telefonica.net> <83oce8fwlq.fsf@gnu.org> <87tyo0a11p.fsf@telefonica.net> <83k4ovg7rn.fsf@gnu.org> <87630fa4j8.fsf@telefonica.net> <83d3unfo92.fsf@gnu.org> <87wrsv8l6u.fsf@telefonica.net> <83bpa7feta.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279315303 2985 80.91.229.12 (16 Jul 2010 21:21:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 21:21:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 16 23:21:41 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZsLk-0005wL-Ht for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 23:21:40 +0200 Original-Received: from localhost ([127.0.0.1]:57249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZsLk-0006gT-0V for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 17:21:40 -0400 Original-Received: from [140.186.70.92] (port=51776 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZsLd-0006em-0J for emacs-devel@gnu.org; Fri, 16 Jul 2010 17:21:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZsLb-0003lZ-Uu for emacs-devel@gnu.org; Fri, 16 Jul 2010 17:21:32 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:33882) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZsLb-0003lP-I0 for emacs-devel@gnu.org; Fri, 16 Jul 2010 17:21:31 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZsLa-0005tJ-5g for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:21:30 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2010 23:21:30 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2010 23:21:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:9kAD2mEf19aJvztwfDFW+cObDxQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127458 Archived-At: Eli Zaretskii 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]