From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: new exporter Date: Sat, 14 Jul 2012 18:20:54 +0200 Message-ID: <87liimfh5l.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:33698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq58e-0004Wj-0z for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:24:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sq58d-0002bw-0a for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:24:11 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:57254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sq58c-0002bk-QT for emacs-orgmode@gnu.org; Sat, 14 Jul 2012 12:24:10 -0400 Received: by weys10 with SMTP id s10so2301400wey.0 for ; Sat, 14 Jul 2012 09:24:08 -0700 (PDT) In-Reply-To: <87ipdrpl5n.fsf@Rainer.invalid> (Achim Gratz's message of "Fri, 13 Jul 2012 20:32:04 +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: Achim Gratz Cc: emacs-orgmode@gnu.org 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. > Thanks. I meanwhile had figured that the limit parameter was missing, > but not if it should always be (point-max). However since you did make > that mistake yourself, maybe you could reconsider the function signature > and perhaps making limit optional and replacing it with (point-max) if > not present (reads as nil)? It seems that it would unclutter the code > for the typical use... `org-element-current-element' is an internal function and (point-max) is an unusual value, albeit sufficient for testing purpose. Regards, -- Nicolas Goaziou