From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: new exporter / org-element Date: Thu, 25 Oct 2012 22:37:25 +0200 Message-ID: <87r4omjnju.fsf@gmail.com> References: <87sj937lao.fsf@Rainer.invalid> <87ip9zmwp1.fsf@gmail.com> <871ugmn3sy.fsf@gmail.com> <871ugm1g6l.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRUEu-0003bY-Ko for emacs-orgmode@gnu.org; Thu, 25 Oct 2012 16:41:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRUEt-00046H-HO for emacs-orgmode@gnu.org; Thu, 25 Oct 2012 16:41:16 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:60465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRUEt-000468-Az for emacs-orgmode@gnu.org; Thu, 25 Oct 2012 16:41:15 -0400 Received: by mail-wi0-f171.google.com with SMTP id hj13so4878870wib.12 for ; Thu, 25 Oct 2012 13:41:14 -0700 (PDT) In-Reply-To: <871ugm1g6l.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 25 Oct 2012 21:53: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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > Thanks for the suggestion, but again I'm using this just as an > example. I understand, but this example doesn't help, since it can't justify the need for any additional mechanism you're suggesting. >> There's already such a mechanism: it's called "filters". I'm just >> pointing out that, in your situation, it's not worth relying on this >> kind of tool. > > IIUC, you are talking about a mechanism to implement exporters. Absolutely not. Filters are end-user tools used to tweak output from back-ends (that is a string to string process). > I'm vying for a way to syntactically tie stuff that needs to go before > the element (and maybe wrap around it) so that it's recognized as part > of that element and not part of another, unrelated element. That's too vague. It depends on the type of element, the level at which you want to tie stuff (in Org buffer, in the parse tree, just before export) and the frequency at which you'll need it. In most cases, I imagine adding #+LATEX: (or any other appropriate keyword) around the element is enough. Regards,