From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Build fail with emacs 24.3.1 Date: Thu, 14 Mar 2013 13:28:56 +0100 Message-ID: <871ubiqi5z.fsf@bzg.ath.cx> References: <4213D585-9331-41E2-AA2B-03550D3E043B@univie.ac.at> <878v5reck1.fsf@bzg.ath.cx> <8738vznjw9.fsf@Rainer.invalid> <87wqtalnlc.fsf@bzg.ath.cx> <87txoete7m.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG7HO-0001jI-Gr for emacs-orgmode@gnu.org; Thu, 14 Mar 2013 08:29:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG7HJ-0004k5-NM for emacs-orgmode@gnu.org; Thu, 14 Mar 2013 08:29:06 -0400 Received: from mail-we0-x22d.google.com ([2a00:1450:400c:c03::22d]:55069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG7HJ-0004js-H1 for emacs-orgmode@gnu.org; Thu, 14 Mar 2013 08:29:01 -0400 Received: by mail-we0-f173.google.com with SMTP id x51so2001944wey.4 for ; Thu, 14 Mar 2013 05:29:00 -0700 (PDT) In-Reply-To: <87txoete7m.fsf@bzg.ath.cx> (Bastien's message of "Thu, 14 Mar 2013 12:26:05 +0100") 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 Hi Achim, Bastien writes: > Yes -- but what I'm arguing about is that the special syntax is not > needed. Or more specifically, it is not needed to have > > (org-export-define-backend html > ((bold . org-html-bold) > > instead of just > > (org-export-define-backend 'html > '((bold . org-html-bold) Some more thought on this. For `org-export-define-derived-backend', my assumption is that the macro mimicks the style of `define-derived-mode': (define-derived-mode CHILD PARENT NAME &optional DOCSTRING &rest BODY) `define-derived-mode' is a macro and both CHILD and PARENT are unquoted symbol names. It makes sense in this case to use this syntax because those symbol names are meant to be accessible to the user as symbols. When I see a (define-derived-mode CHILD...) sexp, I know I can check for the value of CHILD, once derived-defined. This is not the case for `org-export-define-derived-backend', where CHILD and PARENT are not symbols the user wants to check. There are symbols that only have a meaning in `org-export-registered-backends', which is what the users/devs really want to manipulate. So mimicking `define-derived-mode' is confusing here IMHO. Anyway, waiting for Nicolas feedback on this. -- Bastien