From: Nicolas Goaziou <firstname.lastname@example.org> To: email@example.com Subject: Re: Bug in new exporter with babel blocks Date: Sat, 20 Apr 2013 21:32:04 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Aaron Ecay's message of "Thu, 21 Feb 2013 13:11:09 -0500") Hello, Aaron Ecay <firstname.lastname@example.org> writes: > 2013ko urtarrilak 23an, Nicolas Goaziou-ek idatzi zuen: >> You needn't. org-exp-blocks functionalities are supported by the new >> exporter out of the box. > > Can you say more about this? I looked for but did not find a > replacement to the org-export-blocks variable (an alist associating > block types with functions to export them). I found it very easy to > hook into the new exporter, but perhaps I missed something? No, you didn't miss anything. I was thinking about `org-special-blocks.el'. The exporter doesn't implement org-exp-blocks functionalities. Though, IIRC, org-exp-blocks was mostly deprecated when Babel was introduced. That's why old ditaa and dot "exp-blocks" were moved to src block languages. > For parsing, yes. But for export I want a way to say “I don’t care what > Org thinks the export of this block is. Give me the raw contents, and I > will tell you what the export should be.” > > This is how the ditaa special-block code used to work; I see that it has > now morphed into a babel language, which makes some kind of sense. I’m > not sure it does in general. > > My use case is glossed examples for linguistics: my special block > contains three lines, which are a sentence in a foreign language and a > translation. By inserting markup in a way which is easy to automate, > you can get LaTeX to align the words of one language with the words of > the other. I don’t want any org processing of the text of the examples: > it might contain backslashes, stars, etc., all of which should be passed > verbatim to LaTeX. This does not feel like source code, it cannot be > evaluated or tangled, I would not want these blocks to be included in > org-babel-next-src-block, etc. It is data. Source code is for the processing function. Anyway, just store your text in example blocks, and create a src block in any language to do the processing. Then you can call the processing function on all of your example blocks. I suggest to keep the example blocks in a non-exportable section. You can also remove all named example blocks before export, via a hook. Your call. #+begin_src org * Data :noexport: #+name: words #+BEGIN_EXAMPLE a b c #+END_EXAMPLE #+name: #+BEGIN_SRC emacs-lisp :var x=words (upcase x) #+END_SRC * Contents #+call: words(:var x=words) #+end_src Regards, -- Nicolas Goaziou
prev parent reply other threads:[~2013-04-20 19:32 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-22 21:54 Aaron Ecay 2013-01-23 13:28 ` Nicolas Goaziou 2013-02-21 18:11 ` Aaron Ecay 2013-04-20 19:32 ` Nicolas Goaziou [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Bug in new exporter with babel blocks' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).