Re: Import Reusable org-babel snippet using #+SETUPFILE
Hey Doug, What types of things are in GeneralORGTools.org? Are those babel definitions? Or something else? -s- On Tue, Jun 16, 2020 at 11:21 AM Salomon Turgman wrote: > Thanks for the useful example. I will take a look. Didn't know about > org-sbe! > > -s- > > On Mon, 15 Jun 2020 15:52:16 -0400 > Douglas Perrin wrote: > > > Hi Salomon Turgman, > > I do this a lot and have had success using a combination of #+SETUPFILE > to > > bring in names and configuration, and org-sbe to do initialization. I mix > > emacs vars and org names in my source headers with back quoting. > > > > The following example has a template file containing user/local > > information. This is brought into the example file, on load, through > #:eval > > calling org-babel-lob-ingest and org-sbe, in addition, parameters are > > pulled in with #+SETUPFILE and the same template file name. The end > result > > for this example is a running docker image with access to local paths and > > "remote" execution via tramp. More complex orchestration and actions in > the > > template are certainly possible using org-sbe calls in the init elisp > > source blocks but hopefully, this shows the flavor of what can be done. > > > > In addition to avoiding code duplication, I have found this to be very > > effective when my group is all working from the same org file (via git) > but > > everyone has their own template file with credentials, local paths, and > org > > more preferences (ie showstars). > > Regards, > > Doug > > > > > - > > TemplatingExample.org > > > - > > #+SETUPFILE: Template-Loader.org > > > > * Init Code, run when file is opened > > #+name: Execute-On-Load > > #+begin_src elisp :results output > >;; for this the container and image have the same name > > (setq *DockerName* "ContanerName") > > #+end_src > > > > * Run Contaner > > #+begin_src bash :results raw drawer :var DockerName=`,*DockerName* > > DockerHubUID=`,*DockerHubUID* containerName=`,*DockerContainer* > > LocalWorkPath=`,*LocalWorkPath* LocalDataPath=`,*LocalDataPath* > >docker run --rm -d \ > > -v $LocalWorkPath:/root/Workdir \ > > -v $LocalDataPath:/root/Data \ > > --name $DockerName $DockerHubUID/$DockerName bash -c "tail -f > > /dev/null" > > #+end_src > > > > * run IN contaner > > #+begin_src bash :results output :dir (concat "/docker:" `,*DockerName* > > ":/root/Workdir/") > > ls > > #+end_src > > > > # Local Variables: > > # eval: (org-babel-lob-ingest "Template-Loader.org") > > # eval: (org-sbe "Init-Template") > > # eval: (org-sbe "Execute-On-Load") > > # End: > > > > > - > > Template-Loader.org > > > - > > #+STARTUP: showstars > > #+PROPERTY: header-args :mkdirp yes > > > > #+name: Init-Template > > #+begin_src emacs-lisp :results none > > ;; This is called expecitly via org-sbe in the buffer that will uses > the > > templating > > (setq *DockerHubUID* "MyUserName") > > (setq *LocalWorkPath* "/run/desktop/mnt/host/c/Users/.") > > (setq *LocalDataPath* "/run/desktop/mnt/host/d/devData/") > > > > ;; ingest + SBE can be used to bring in a hierarchy of templates > > (org-babel-lob-ingest "./GroupTools/GeneralORGTools.org") > > (org-sbe "GeneralORGTools.org") > > > > #+end_src > > > -- > Salomon Turgman >
Re: Import Reusable org-babel snippet using #+SETUPFILE
Thanks for the useful example. I will take a look. Didn't know about org-sbe! -s- On Mon, 15 Jun 2020 15:52:16 -0400 Douglas Perrin wrote: > Hi Salomon Turgman, > I do this a lot and have had success using a combination of #+SETUPFILE to > bring in names and configuration, and org-sbe to do initialization. I mix > emacs vars and org names in my source headers with back quoting. > > The following example has a template file containing user/local > information. This is brought into the example file, on load, through #:eval > calling org-babel-lob-ingest and org-sbe, in addition, parameters are > pulled in with #+SETUPFILE and the same template file name. The end result > for this example is a running docker image with access to local paths and > "remote" execution via tramp. More complex orchestration and actions in the > template are certainly possible using org-sbe calls in the init elisp > source blocks but hopefully, this shows the flavor of what can be done. > > In addition to avoiding code duplication, I have found this to be very > effective when my group is all working from the same org file (via git) but > everyone has their own template file with credentials, local paths, and org > more preferences (ie showstars). > Regards, > Doug > > - > TemplatingExample.org > - > #+SETUPFILE: Template-Loader.org > > * Init Code, run when file is opened > #+name: Execute-On-Load > #+begin_src elisp :results output >;; for this the container and image have the same name > (setq *DockerName* "ContanerName") > #+end_src > > * Run Contaner > #+begin_src bash :results raw drawer :var DockerName=`,*DockerName* > DockerHubUID=`,*DockerHubUID* containerName=`,*DockerContainer* > LocalWorkPath=`,*LocalWorkPath* LocalDataPath=`,*LocalDataPath* >docker run --rm -d \ > -v $LocalWorkPath:/root/Workdir \ > -v $LocalDataPath:/root/Data \ > --name $DockerName $DockerHubUID/$DockerName bash -c "tail -f > /dev/null" > #+end_src > > * run IN contaner > #+begin_src bash :results output :dir (concat "/docker:" `,*DockerName* > ":/root/Workdir/") > ls > #+end_src > > # Local Variables: > # eval: (org-babel-lob-ingest "Template-Loader.org") > # eval: (org-sbe "Init-Template") > # eval: (org-sbe "Execute-On-Load") > # End: > > - > Template-Loader.org > - > #+STARTUP: showstars > #+PROPERTY: header-args :mkdirp yes > > #+name: Init-Template > #+begin_src emacs-lisp :results none > ;; This is called expecitly via org-sbe in the buffer that will uses the > templating > (setq *DockerHubUID* "MyUserName") > (setq *LocalWorkPath* "/run/desktop/mnt/host/c/Users/.") > (setq *LocalDataPath* "/run/desktop/mnt/host/d/devData/") > > ;; ingest + SBE can be used to bring in a hierarchy of templates > (org-babel-lob-ingest "./GroupTools/GeneralORGTools.org") > (org-sbe "GeneralORGTools.org") > > #+end_src -- Salomon Turgman
Import Reusable org-babel snippet using #+SETUPFILE
Hello all, I have created what I hoped was a reusable org-babel snippet that looks like this: #+NAME: simulation #+HEADER: :var cap="DEFAULTCAPTION" :cache yes :eval no-export :var altimage="1_image.svg#img1" #+BEGIN_SRC emacs-lisp :var divid="defid" :var num=1 :results html :exports results (format "cool string that uses parameters %s %s ..." num cap divid altimage (capitalize divid) divid) #+END_SRC I will use this snippet with something like: #+CALL: simulation(cap="bam", num=1, divid="bamid"...) Now, if I include the definition in every org file that I want to use it, everything works well. However, if I include the definition in a central org file that I import using #+SETUPFILE, things break and I don't get the proper output in my html exports. Is there a way that I can "import" that snippet without rewriting it in every file I need it? Thanks in advance! -s-
Re: How to add new type of block to a derived back-end?
Ok... just reporting back my progress in case it helps someone else. Bur
first, all the stuff that you can do with src blocks is stuff I never
imagined. Seems like the possibilities are endless. Here is what I did so
far:
#+NAME: simulation
#+HEADER: :var cap="DEFAULTCAPTION" :cache yes :eval no-export :var
altimage="1_image.svg#img1"
#+BEGIN_SRC emacs-lisp :var divid="defid" :var num=1 :results html :exports
results
(format
"Simulation %s: %s
var app = Elm.%s.init({node:
document.getElementById(\"%s\")});"
num cap divid altimage (capitalize divid) divid)
#+END_SRC
That is my "definition"... I call it like this:
#+CALL: simulation(cap="Manual control of tank level", num=1,
divid="main1", altimage="1_manual_noscript.svg")
And it seems to work beautifully. Still need to figure out the counting of
the number of simulations per page... but that should be trivial at this
point. Thank you so much for all the pointers.
-s-
On Fri, Apr 10, 2020 at 1:14 PM Salomon Turgman wrote:
> Thank you very much. I will explore what you suggest. I'm glad I emailed,
> seems like I was going down the wrong path.
>
> Salomon
>
> On Fri, Apr 10, 2020, 1:10 PM Berry, Charles
> wrote:
>
>> Salomon, see inline comments below.
>>
>> HTH,
>>
>> Chuck
>>
>> > On Apr 10, 2020, at 7:56 AM, Salomon Turgman
>> wrote:
>> >
>> > Hello all,
>> >
>> > Thanks in advance for any hints you can provide for this. I am trying
>> to create a derived back-end that handles a new type of block in org-mode.
>> I am trying to derive using the html export backend as a parent.
>> >
>> > Currently I am solving my problem like this:
>> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
>> level.
>> > #+BEGIN_EXPORT html
>> > Simulation 1: Manual control of the tank
>> level.
>> >
>> >
>> >
>> > Some other cool stuff here.
>> >
>> >
>> >
>> > var app = Main1.init({node:
>> document.getElementById("main1")});
>> > #+END_EXPORT
>> >
>> > This has a few downsides:
>> > 1. I have to specify the caption twice since export translator does not
>> handle captions.
>> > 2. I have to include substantial amounts of html.
>> > 3. I have keep track of references to simulations manually (simulation
>> 1, simulation 2, etc)
>> > 4. I have to include the identifier `main1` or `Main1` in several
>> locations in the snippet.
>> >
>> > I could solve some of this with an automated snippet insertion tool but
>> I thought that maybe I can get the export back-end to do most of the work
>> for me.
>> >
>> > So I am trying to derive as follows (in pseudo-elisp-code):
>> > (require 'ox)
>> > (require 'ox-html)
>> >
>> > (org-export-define-derived-backend 'textbook 'html
>> > :menu-entry
>> > '(?I "Export textbook section"
>> >((?b "To buffer" org-html-export-as-html)
>> > (?I "To file" org-html-export-to-html)
>> > (?o "As HTML file and open"
>> > (lambda (a s v b)
>> > (if a (org-html-export-to-html t s v b)
>> > (org-open-file (org-html-export-to-html nil s v
>> b)))
>> > :translate-alist '((simulation . org-textbook-simulation)))
>>
>> From the `org-export-define-backend' docstring:
>>
>> "TRANSCODERS is an alist between object or element types and
>> functions handling them."
>>
>> But `simulation' is not such a type. So, this will not work.
>>
>> >
>> > (defun org-textbook-simulation (element contents info)
>> > (let* ((simnum (extract simnum value))
>> > (caption (org-export-get-caption element))
>> > (divid (extrac divid value))
>> > (modid (convert divid into modid))
>> > )
>> > (format "Simulation %simnum%:
>> %Caption%.
>> >
>> >
>> >
>> >
>> > var app = %modid%.init({node:
>> document.getElementById(\"%divid%\")});"
>> >simnum caption divid modid divid)))
>> >
>> > With the hope that I can do something like this in my .org file:
>> >
>> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
>> level.
>&
Re: How to add new type of block to a derived back-end?
Thank you very much. I will explore what you suggest. I'm glad I emailed,
seems like I was going down the wrong path.
Salomon
On Fri, Apr 10, 2020, 1:10 PM Berry, Charles
wrote:
> Salomon, see inline comments below.
>
> HTH,
>
> Chuck
>
> > On Apr 10, 2020, at 7:56 AM, Salomon Turgman wrote:
> >
> > Hello all,
> >
> > Thanks in advance for any hints you can provide for this. I am trying to
> create a derived back-end that handles a new type of block in org-mode. I
> am trying to derive using the html export backend as a parent.
> >
> > Currently I am solving my problem like this:
> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
> level.
> > #+BEGIN_EXPORT html
> > Simulation 1: Manual control of the tank
> level.
> >
> >
> >
> > Some other cool stuff here.
> >
> >
> >
> > var app = Main1.init({node:
> document.getElementById("main1")});
> > #+END_EXPORT
> >
> > This has a few downsides:
> > 1. I have to specify the caption twice since export translator does not
> handle captions.
> > 2. I have to include substantial amounts of html.
> > 3. I have keep track of references to simulations manually (simulation
> 1, simulation 2, etc)
> > 4. I have to include the identifier `main1` or `Main1` in several
> locations in the snippet.
> >
> > I could solve some of this with an automated snippet insertion tool but
> I thought that maybe I can get the export back-end to do most of the work
> for me.
> >
> > So I am trying to derive as follows (in pseudo-elisp-code):
> > (require 'ox)
> > (require 'ox-html)
> >
> > (org-export-define-derived-backend 'textbook 'html
> > :menu-entry
> > '(?I "Export textbook section"
> >((?b "To buffer" org-html-export-as-html)
> > (?I "To file" org-html-export-to-html)
> > (?o "As HTML file and open"
> > (lambda (a s v b)
> > (if a (org-html-export-to-html t s v b)
> > (org-open-file (org-html-export-to-html nil s v
> b)))
> > :translate-alist '((simulation . org-textbook-simulation)))
>
> From the `org-export-define-backend' docstring:
>
> "TRANSCODERS is an alist between object or element types and
> functions handling them."
>
> But `simulation' is not such a type. So, this will not work.
>
> >
> > (defun org-textbook-simulation (element contents info)
> > (let* ((simnum (extract simnum value))
> > (caption (org-export-get-caption element))
> > (divid (extrac divid value))
> > (modid (convert divid into modid))
> > )
> > (format "Simulation %simnum%: %Caption%.
> >
> >
> >
> >
> > var app = %modid%.init({node:
> document.getElementById(\"%divid%\")});"
> >simnum caption divid modid divid)))
> >
> > With the hope that I can do something like this in my .org file:
> >
> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
> level.
> > #+BEGIN_SIMULATION main1
> > Some other cool stuff here
> > #+END_SIMULATION
>
>
> I think an easier approach is to write a babel src-block that formats the
> inputs you need and creates a value that is your desired output.
>
> Use `:var' header arguments to define the inputs.
>
> Use `:wrap html' to prevent the exporter from changing the output.
>
> Subsequent calls can use the `#+CALL' idiom.
>
> You can use any scripting language that suits you - elisp, python, shell,
> R, ... --- for this purpose.
>
> If you are skilled in emacs-lisp you might write an `eval' macro instead
> of a src block.
>
> >
> > Am I on the right track here? Can someone point me to an example on how
> to:
> > 1. Keep track of the number of simulations for referencing?
>
> Using the babel approach, you would need a `:session' with a persistent
> variable that would hold the count. You would need to initialize it in your
> document so that subsequent exports will start counting at zero.
>
> > 2. Extract the caption properly? The above is just my guess.
>
>
> IIRC, the info channel is not populated when babel runs, so you will need
> to parse the src-block and extract the `:caption' element. I think you can
> use a `:var cap=(find-caption)' idiom, where `find-caption' is a function
> you write using `org-element-context' as a starting point.
>
> Or if the only need you have for the caption is within that src block just
> use `:var cap="".
>
> > 3. Extract the divid value (main1)
>
> :var divid="main1"
>
>
> > 4. And finally, how to get org to recognize the new SIMULATION block so
> that it can apply `org-textbook-simulation`? Do I need to register this
> type of block somewhere? Or is the name of the first member of the
> :translate-alist translation pair have some special meaning?
>
> Don't go in that direction. Use babel or write an eval macro.
>
> [snip]
>
How to add new type of block to a derived back-end?
Hello all,
Thanks in advance for any hints you can provide for this. I am trying to
create a derived back-end that handles a new type of block in org-mode. I
am trying to derive using the html export backend as a parent.
Currently I am solving my problem like this:
#+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
#+BEGIN_EXPORT html
Simulation 1: Manual control of the tank level.
Some other cool stuff here.
var app = Main1.init({node:
document.getElementById("main1")});
#+END_EXPORT
This has a few downsides:
1. I have to specify the caption twice since export translator does not
handle captions.
2. I have to include substantial amounts of html.
3. I have keep track of references to simulations manually (simulation 1,
simulation 2, etc)
4. I have to include the identifier `main1` or `Main1` in several locations
in the snippet.
I could solve some of this with an automated snippet insertion tool but I
thought that maybe I can get the export back-end to do most of the work for
me.
So I am trying to derive as follows (in pseudo-elisp-code):
(require 'ox)
(require 'ox-html)
(org-export-define-derived-backend 'textbook 'html
:menu-entry
'(?I "Export textbook section"
((?b "To buffer" org-html-export-as-html)
(?I "To file" org-html-export-to-html)
(?o "As HTML file and open"
(lambda (a s v b)
(if a (org-html-export-to-html t s v b)
(org-open-file (org-html-export-to-html nil s v b)))
:translate-alist '((simulation . org-textbook-simulation)))
(defun org-textbook-simulation (element contents info)
(let* ((simnum (extract simnum value))
(caption (org-export-get-caption element))
(divid (extrac divid value))
(modid (convert divid into modid))
)
(format "Simulation %simnum%: %Caption%.
var app = %modid%.init({node:
document.getElementById(\"%divid%\")});"
simnum caption divid modid divid)))
With the hope that I can do something like this in my .org file:
#+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
#+BEGIN_SIMULATION main1
Some other cool stuff here
#+END_SIMULATION
Am I on the right track here? Can someone point me to an example on how to:
1. Keep track of the number of simulations for referencing?
2. Extract the caption properly? The above is just my guess.
3. Extract the divid value (main1)
4. And finally, how to get org to recognize the new SIMULATION block so
that it can apply `org-textbook-simulation`? Do I need to register this
type of block somewhere? Or is the name of the first member of the
:translate-alist translation pair have some special meaning?
Thank you very much for any assistance and thank you for org-mode!
-s-
