From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: new exporter Date: Sat, 14 Jul 2012 23:17:52 +0530 Message-ID: <811ukejktz.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> <81bojijnkk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:40087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq6Rx-0002Bf-0f for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 13:48:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sq6Rv-0002Hg-GC for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 13:48:12 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:63627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq6Rv-0002Eb-9u for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 13:48:11 -0400 Received: by pbbrp2 with SMTP id rp2so8502203pbb.0 for ; Sat, 14 Jul 2012 10:48:10 -0700 (PDT) In-Reply-To: <81bojijnkk.fsf@gmail.com> (Jambunathan K.'s message of "Sat, 14 Jul 2012 22:18:43 +0530") 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 Jambunathan K writes: > 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. Do table-cell gets "composed" in a special way wrt other elements. > 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. I dont't have handle on it yet. May be it is just a coincidence that the translation involves lists and tables. ps: If only there way to see the C pointers underlying the objects one could actually sensibly see what is happening underneath. The closest I have come to doing so is to use a combination of `pp-display-expression' with (setq print-circle t). This latter part was added to my .emacs only in the last 2 days in an effort to bring out the differnce between `eq' and `equal'. For example a table like this | 1 | 2 | | a | b | gets rendered as below. Track the :parent properties, the Ns and #es and you have no ambiguity on what objects they point to. #1=(org-data nil #2=(section (:begin 2 :end 22 :contents-begin 2 :contents-end 22 :post-blank 0 :parent #1#) #3=(table (:begin 2 :end 22 :type org :tblfm nil :contents-begin 2 :contents-end 22 :value nil :post-blank 0 :parent #2#) #4=(table-row (:type standard :begin 2 :end 12 :contents-begin 3 :contents-end 11 :post-blank 0 :parent #3#) (table-cell (:begin 3 :end 7 :contents-begin 4 :contents-end 5 :post-blank 0 :parent #4#) "1") (table-cell (:begin 7 :end 11 :contents-begin 8 :contents-end 9 :post-blank 0 :parent #4#) "2")) #5=(table-row (:type standard :begin 12 :end 22 :contents-begin 13 :contents-end 21 :post-blank 0 :parent #3#) (table-cell (:begin 13 :end 17 :contents-begin 14 :contents-end 15 :post-blank 0 :parent #5#) "a") (table-cell (:begin 17 :end 21 :contents-begin 18 :contents-end 19 :post-blank 0 :parent #5#) "b")))))