1

I write academic articles with org mode. Sometimes I'd like to keep things clustered in no-op blocks, just so I can identify them later. An example would be reviewer comments or changes:

* Methods

We did a bit of this and that.

#+begin_revision
# Reviewer said our methods weren't clear enough
In this we collected data from N participants...
In that we analysed the data as described in X.
#+end_revision

I don't want drawers because I don't want to keep things hidden per default. I'd prefer to have a no-op block, whereby its content goes to export as if the block didn't exist at all. The advantage is that If I ever went back to the manuscript years later, I'd still have this "meta" block information in there.

I know I could use the :ignore: tag and have an extra heading, but I feel these comments don't really belong in the document hierarchy.

Are there NO-OP blocks? Or what would be the best way to implement them?

4
  • 2
    What about comment blocks?
    – Juancho
    Commented Jul 6, 2019 at 20:38
  • Thanks, learned something new. Yet, comment blocks are not exported. I want to group pieces of text that should be exported and visible, yet not part of the document hierarchy.
    – Daniel
    Commented Jul 6, 2019 at 20:57
  • 1
    What you describe looks to me just like a comment, e.g., # begin_revision and # end_revision without the + sign. such that orgmode does not recognize it. It is only your own convention.
    – Tobias
    Commented Jul 6, 2019 at 23:25
  • Here's how you could define them: (defblock revision nil nil "A no-op block." contents) ---this now just works when alhassy.github.io/org-special-block-extras is enabled. Commented Feb 26, 2021 at 3:26

1 Answer 1

2

Such an unknown block is called a special block.

In org 9.0.3, section 11.8 of documentation ("Special blocks") says:

Each export back-end decides if they should be exported, and how. When the block is ignored, its contents are still exported, as if the opening and closing block lines were not there.

In section 12.15 (Exporting/Advanced configuration) the use of filters is described:

Filters are lists of functions applied on a specific part of the output from a given back-end. More explicitly, each time a back-end transforms an Org object or element into another language, all functions within a given filter type are called in turn on the string produced. The string returned by the last function will be the one used in the final output.

There are filters sets for each type of element or object, for plain text, for the parse tree, for the export options and for the final output. They are all named after the same scheme: ‘org-export-filter-TYPE-functions’, where ‘TYPE’ is the type targeted by the filter.

special block is one such type, so you could do:

(defun my-export-no-special-block (text backend info)
  "Do not export the content of special blocks."
  "")

(add-to-list 'org-export-filter-special-block-functions
         'my-export-no-special-block)

Note this will turn off exporting of all special blocks (not just revision), for all backends.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.