From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export Date: Fri, 19 Sep 2014 21:29:28 +0200 Message-ID: <87bnqbv27b.fsf@nicolasgoaziou.fr> References: <87k34zqv9r.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XV3rZ-0006Kc-GJ for emacs-orgmode@gnu.org; Fri, 19 Sep 2014 15:29:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XV3rP-0006Wh-CP for emacs-orgmode@gnu.org; Fri, 19 Sep 2014 15:29:01 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:52121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XV3rP-0006W0-7B for emacs-orgmode@gnu.org; Fri, 19 Sep 2014 15:28:51 -0400 Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 1ADEFFB881 for ; Fri, 19 Sep 2014 21:28:45 +0200 (CEST) Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id oC6-qMcCX0yB for ; Fri, 19 Sep 2014 21:28:43 +0200 (CEST) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9A62CFB87D for ; Fri, 19 Sep 2014 21:28:43 +0200 (CEST) In-Reply-To: <87k34zqv9r.fsf@gmail.com> (Aaron Ecay's message of "Fri, 19 Sep 2014 15:12:48 -0400") 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: Org-mode Hello, Aaron Ecay writes: > Currently, if a macro is not defined, it will silently produce an empty > string while exporting. This situation could arise for example if a > macro name is acidentally mistyped. I think it=E2=80=99s desirable to wa= rn the > user in this case. The attached patch introduces a function to do so, > and shows how it would be integrated in the latex backend. This raises > several questions: > > 1. Should the warning be a =E2=80=9Cmessage=E2=80=9D (allows the export p= rocess to > continue) or a =E2=80=9Cuser-error=E2=80=9D (stops the export process)= ? Or, should > this be configurable? Certainly not a message, due to asynchronous export. > 2. Since this is a feature that many backends will want to use, should > we introduce a new =E2=80=9Cabstract=E2=80=9D backend from which other= backends can > inherit, which incorporates this feature, and others like it in the > future? The idea would be similar to prog-mode in emacs, the major > mode from which programming-language modes can derive. The > alternative is adding the (macro . org-export-macro-warn) entry > manually to all the relevant backends, and relying on future backend > authors to do the same. > > 3. Should this even be implemented as part of the backend=E2=80=99s > translate-alist, or at a lower level? Don't bother with export back-ends, they never get to see macros, which are expanded very early in the export process. This explains, for example, why there is no `macro' translator. You have two options. Either report an error, as you suggested, or insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", =C3=A0 la "DEFINITION NOT FOUND." for footnote definitions. In any case, this should happen in "org-macro.el", not in the export framework. Regards, --=20 Nicolas Goaziou