From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: new exporter Date: Sat, 14 Jul 2012 22:18:43 +0530 Message-ID: <81bojijnkk.fsf@gmail.com> References: <3C38420E-E2FA-4CAB-B3FD-9C5F8584E60A@gmail.com> <81fwadrgoo.fsf@gmail.com> <87396dzlai.fsf_-_@Rainer.invalid> <871ulqgb4t.fsf@gmail.com> <87y5nyx4ku.fsf@Rainer.invalid> <87a9zq7htj.fsf@Rainer.invalid> <87r4t261fw.fsf@Rainer.invalid> <87k3yu15wj.fsf@gmail.com> <87395hkj7u.fsf@Rainer.invalid> <87fw9gwmet.fsf@Rainer.invalid> <87pq8j2a0y.fsf@gmail.com> <87r4sy3rve.fsf@Rainer.invalid> <87fw9d1eif.fsf@gmail.com> <878veo6d1a.fsf@Rainer.invalid> <87d340u077.fsf@gmail.com> <87ipdrpl5n.fsf@Rainer.invalid> <87liimfh5l.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq5Wg-0000Ya-Fa for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:49:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sq5Wf-00035F-7m for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:49:02 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:45018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq5Wf-00035B-0S for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:49:01 -0400 Received: by pbbrp2 with SMTP id rp2so8432246pbb.0 for ; Sat, 14 Jul 2012 09:49:00 -0700 (PDT) In-Reply-To: <87liimfh5l.fsf@gmail.com> (Nicolas Goaziou's message of "Sat, 14 Jul 2012 18:20:54 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Achim Gratz , emacs-orgmode@gnu.org Nicolas Goaziou writes: > Hello, > > Achim Gratz writes: > >> Yes, that has been my impression as well. Again, I can make them go >> away by removing one of the byte-compiled files, so I rather suspect >> another case of a macro expansion that's not quite what was intented. >> Only this time I really don't see from the backtrace what that would >> be. > > It looks like table-cells have a wrong `:parent' property when > org-element.el is byte-compiled. In `org-element-table-cell-parser', > replacing backquote with `list' solves the problem. > This is related to modifications by side-effect of list elements, but > I don't know why it only happens when the file is byte-compiled and why > it only focus table cells. There is an interesting "pitfall" mentioned wrt `nconc' under: (info "(elisp) Rearrangement"). I try to make sense of the pitfall by conjuring up this argument. This seems right to me. - `list' will dynamically allocate the list at runtime. It comes from C's heap. - A quote list is allocated at compile time (atleast the constant bits). It comes from memory that is allocated for global variables - externs or static externs. Think value of list is the pointer to an extern C variable. I am not sure what backquote does. Wrt above problem, you may want to verify the following: 1. It works right the first time. But subsequent invocations create side-effect. 2. Focus on what happens to the `head' of the list. I am more or less facing similar problems wrt element translation. I am holding off any checkin mainly because I see some undesirable side-effects. --