Tag: Babel

org-scraps Notes 6CBD47FB-80AD-41DC-9E0C-482FE1C230E6

  • About
    • org-scraps is a collection of Org-Mode demonstrations published by Eric Schulte. All of my experience with Org-Mode Literate Programming is working on my Emacs configuration for Literate Programming. Wanting to address my limited experience I am working through each example in org-scraps. Org-Scraps is weaved to HTML files published here.
  • Approach
    • Evaluate each example.
    • Verify identical result.
    • Update notes on approach.
    • After every reconfiguration re-evaluate DONE examples to verify identical result.
    • Scraps are under-documented. Important ideas are explored often without explicit mention. Sometimes it is obvious; other times not.
  • simple short R block
    • “value table org replace” is probably the best :results configuration for source blocks. Replace table with scalar for in-line source blocks.
  • two blocks and a table
    • Programmatically create tables with org-sbe and #+TBLFM.
  • a table with tags
    • Special blocks like TBLNAME are taggable, for example with :noexport:.
  • shell script output not in table
    • Evaluating a sh SB generates a table with the captured output from echo, with 1 row for each call.
    • Scalar output demands replaceable formatting.
  • space around exported code blocks
    • org-babel-remove-result works no matter where the RESULT block is located. It doesn’t have to immediately follow the Source-Block.
  • scheme sessions
    • ob-scheme allows two sessions with the same name when they were started with different interpreters.

Org2Blog DITAA Test

+--------+   +-------+    +-------+
|        | --+ ditaa +--> |       |
|  Text  |   +-------+    |diagram|
|Document|   |!magic!|    |       |
|     {d}|   |       |    |       |
+---+----+   +-------+    +-------+
    :                         ^
    |       Lots of work      |
    +-------------------------+

0AE23A91-0184-4D16-93F8-8A7D73A6B3E2.png

The test succeeded by turning off thumbnail images.

Migrating to Org2Blog

WordPress is a powerful and satisfying writing and publishing platform. After learning Org-Mode, I wanted to use Org-Mode for writing and WordPress for publishing. Org2Blog makes that easy.

WordPress easily exports your posts to XML. Org2Blog-Importers converts them to Org-Mode via Pandoc. Tonight I converted them here. Any future modifications belong in these documents with publishing to WordPress.

I tested both publishing new posts and modifying and re-publishing old posts and both worked correctly.

How to reintegrate changes for Word back into Org-Mode

Via: 

From:   Ken Mankoff
Subject:  Re: [O] Organizing and taming hectic Academia work (faculty   viewpoint)? Tips or a good guides sought after :)
Date:   Fri, 12 Jun 2015 10:02:50 -0400
Hi Julian,
On 2015-06-10 at 10:16, Julian Burgos <address@hidden> wrote:
> a) I first write in org-mode. Export to Word, either exporting first
> to ODT and then to Word, or to LaTex and then use pandoc to convert
> LaTex to Word. My coauthor can edit the document as he wishes, using
> the "Track changes" option. Then, I transcribe their edits back into
> the org-mode document. Advantage of this approach: your coauthor
> receives a clean word file, that could include figures, references,
> etc., and he/she uses the tools she likes to edit the file.
> Disadvantage: you have to manually incorporate the changes to the
> org-mode file each time there are edits.
>
> b) I write the manuscript in org-mode. Then I send the org-mode file
> to my coauthor. Because the org-mode file is just a text file, my
> coauthor can use Word to edit it. I ask him/her *not* to use "track
> changes" and to save the edited version also as a text file. Then,
> when I receive it I use ediff in emacs to compare both documents and
> incorporate the edits I want. Advantage of this approach: the merging
> of the documents is easy using ediff. Disadvantage: your coauthor has
> to edit a weird-looking document, with markup, code blocks, etc.
It seems like with a bit of extra (scriptable?) work you could remove both
disadvantages.
Why can't you use method (a) above, and then DOCX -> Org via pandoc (with
--accept-all option)?
I know pandoc introduce some of its own changes to the Org syntax but not the
document itself. You can get around this. You can remove the pandoc-generated
changes automagically so that only co-author changes appear in Org format,
which you can then use with your (b) above and emacs ediff.
Original: Your Org source
A: Org -> DOCX for co-authors (using pandoc)
B: Org -> DOCX -> Org (using pandoc).
C: A -> Org (using pandoc and --accept-all-changes)
D: B-Original
The difference between B and Original are pandoc-introduced changes that you do
not want. Ignore/remove these changes from C, call it D and then the difference
between D and the Original are your co-author comments. Now your authors can
edit DOCX with Track Changes and you can work on those edits with Emacs ediff.
  -k.

Uniquely Name Source-Blocks and Headline IDs in Org-Mode

Always name all of your Source-Blocks and uniquely ID Headlines in Org-Mode. It is the only way to make Literate Programming pleasant and predictable. At the very least you will understand what is happening during tangling.

Org-Mode Release 8.3

Org 8.3 is now out.

Addendum: 2015-08-16
Interesting:

  • org-show-context-detail
  • Markdown export supports switches in source blocks
  • ASCII export additions
  • Export inline source blocks
  • ascii plot
  • date macro parms
  • mathjax cdn
  • viewport for html mobile
  • remotely edit footnote definition
  • texinfo image support
  • Removed option org-koma-letter-use-title
  • Three slash URI links
  • Footnotes in included files are now local to the file
  • When exporting, throw an error on unresolved id/fuzzy links and code refs