Re: setting a custom flag for src blocks

[Matt Price <moptop99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

Huh.  This is pretty cool, Charles. But I think it will be a little hard
for me to implement for lectures, since I really need to quickly write up
slides in the half-hour before class...  So, instead, I rewrote
org-reveal-src-block to do the work for me. I've just written a blog post
-- for some reason my posts are no longer showing up on Planet Emacsen
(maybe b/c I have soem non-Emas stuff o nthat blog now), but the blog is
here:

http://matt.hackinghistory.ca/2016/12/11/org-mode-run-code-live-in-a-reveal-slideshow-with-klipse/

I would really love to get feedback on this solution, or any other ones.
Thanks as always to all readers and commentators!

On Sun, Dec 11, 2016 at 12:19 AM, Charles C. Berry <ccberry@ucsd.edu> wrote:

> On Sat, 10 Dec 2016, Matt Price wrote:
>
> On Sat, Dec 10, 2016 at 12:19 AM, Matt Price <moptop99@gmail.com> wrote:
>>
>>
>>>
>>> On Fri, Dec 9, 2016 at 12:19 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>>>
>>> On Friday,  9 Dec 2016 at 16:42, Matt Price wrote:
>>>>
>>>>> I think I am getting closer, actually (details soon, when I have a
>>>>> fully working  solution)).
>>>>>
>>>>
> [deleted]
>
> I *think* that I'm looking for an export filter. From what I can see, it
>> has access to all the information that  the  initial export function does.
>>
>
> It does not. :-(
>
> When `org-babel-exp-process-buffer' runs (under `org-export-as'), all the
> header info is dropped.
>
> There might be a way to backtrack from the copy buffer to the original and
> remap the src blocks, but it seems like the wrong way to go. It would be a
> lot of work, I think.
>
> More below ...
>
> So now I'm wondering what the easiest way is to set a simple flag for a src
>> block, and make that flag available to the export filter.  For instance,
>> if
>> I want a particular block to be renderd in klipse on export, could I
>> specify somehow:
>>
>> #+HEADER: klipsify t
>> #+BEGIN_SRC: javascript
>> console.log("success");
>> #+END_SRC
>>
>> or alternatively in a subtree:
>>
>> * Lots of Examples
>> :PROPERTIES:
>> #+PROPERTY: header-args:javascript  :klipsify t
>> :END:
>>
>> #+BEGIN_SRC: javascript
>> console.log("success");
>> #+END_SRC
>>
>>
> I think the better way to go is to do all the formatting in babel. That
> is, make a babel src block handle the formatting for you and subvert the
> normal mechanisms.
>
> To do this, write a src block that is given the name of another src
> block, that grabs the body (and if you really need it the header
> info), formats it as you need, and inserts it in final form wrapped
> in an `export html' block.
>
> So if you had a src block named `codeA' and one named `klipsify' which
> has the code needed to render the output you desire depending on the
> value of
>
> : :var src-blk-name="my-codes"
>
> then a
>
> #+CALL:klipsify("codeA")
>
> line will put the output in the exported document.
>
> Something like this:
>
> #+NAME: codeA
> #+BEGIN_SRC: javascript :eval never-export :exports none
> console.log("success");
> #+END_SRC
>
> #+NAME: klipsify
> #+header: :var src-blk-name="my-code" :exports none
> #+header: :results raw :wrap export html
> #+BEGIN_SRC emacs-lisp
>   (save-excursion
>     (org-babel-goto-named-src-block
>      src-block-name)
>     (let ((body-code
>            (org-babel-expand-src-block)))
>       (klipsify-my-code body-code)))
> #+END_SRC
>
> Obviously, you need to defun `klipsify-my-code' or whatever.
>
>
> All the code blocks would need to be named and have these headers:
>
> :  :eval never-export :exports none
>
> or maybe
>
> :  :exports results
>
> You would use the latter, if you want the results of evaluating the code
> to appear in the exported document. Put the #+CALL line just before the
> code block and then the code will appear first and the results next.
>
> HTH,
>
> Chuck
>

[-- Attachment #2: Type: text/html, Size: 5542 bytes --]