getting access to a self-invented option?

getting access to a self-invented option?

[Matt Price]

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

I'm trying to streamline some veyr ad-hoc workflows I have. One thing I do
a lot during the school year is make some changes to an org source file,
and then export to hugo markdown with ox-hugo, and finally commit to git
(after that I have a git hook that generates the website & uploads the
changed pages to the appropriate location, usually a github-pages branch or
separate repo).

So I have this code:

(defun mwp-hugo-export-and-release ()
  "Make it faster and easier to put my lectures up on the website."
  (interactive)

  (let* ((modfile (org-hugo-export-wim-to-md))
         (basedir (plist-get  (org-export-get-environment 'hugo)
':hugo-base-dir ))
         (default-directory (expand-file-name basedir)))
    (magit-stage-file modfile)
    ;; (magit-status)
    (magit-commit-create)
    )  )

It works great, I'm very happy. HOWEVER: in my websites I have two kinds of
outputs:

- regular pages -- these get exported to .md files and turned into html by
hugo
- lecture notes -- these get exported to reveal.js HTML pages by
org-re-reveal and my hugo theme treats them differently .

I would really like to set a switch somewhere in the file, something like:

#+MWP_EXPORT_TYPE: slides

And then something like

let* ((modfile (if (eq :mwp-export-type "slides")
(mwp-hugo-reveal-custom-export-function)
                               (org-hugo-export-wim-to-md)))
     ....etc)
            do stuff)


But I'm not sure how to get access to a totally non-standard option like
the kind I just invented in that last bit of pseudo-code. Anyone have a
good suggestion?

Thank you as always!

Matt

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

Re: getting access to a self-invented option?

[Tim Cross]

Could you just use a tag for this? My shallow thought is that if you
tagged headlines, over time you could use different tags for different
content type whereas if you use a new custom type, you would need to
repeat the definition process (whatever that might be) every time you
discovered a new required type. This would also enable you to benefit
from some of the other nice attributes of tags, such as inheritance.

Matt Price <moptop99@gmail.com> writes:

> I'm trying to streamline some veyr ad-hoc workflows I have. One thing I do
> a lot during the school year is make some changes to an org source file,
> and then export to hugo markdown with ox-hugo, and finally commit to git
> (after that I have a git hook that generates the website & uploads the
> changed pages to the appropriate location, usually a github-pages branch or
> separate repo).
>
> So I have this code:
>
> (defun mwp-hugo-export-and-release ()
>   "Make it faster and easier to put my lectures up on the website."
>   (interactive)
>
>   (let* ((modfile (org-hugo-export-wim-to-md))
>          (basedir (plist-get  (org-export-get-environment 'hugo)
> ':hugo-base-dir ))
>          (default-directory (expand-file-name basedir)))
>     (magit-stage-file modfile)
>     ;; (magit-status)
>     (magit-commit-create)
>     )  )
>
> It works great, I'm very happy. HOWEVER: in my websites I have two kinds of
> outputs:
>
> - regular pages -- these get exported to .md files and turned into html by
> hugo
> - lecture notes -- these get exported to reveal.js HTML pages by
> org-re-reveal and my hugo theme treats them differently .
>
> I would really like to set a switch somewhere in the file, something like:
>
> #+MWP_EXPORT_TYPE: slides
>
> And then something like
>
> let* ((modfile (if (eq :mwp-export-type "slides")
> (mwp-hugo-reveal-custom-export-function)
>                                (org-hugo-export-wim-to-md)))
>      ....etc)
>             do stuff)
>
>
> But I'm not sure how to get access to a totally non-standard option like
> the kind I just invented in that last bit of pseudo-code. Anyone have a
> good suggestion?
>
> Thank you as always!
>
> Matt


--
Tim Cross

Re: getting access to a self-invented option?

[Thibault Marin]

Hi,

I am not sure where you are trying to get to the value (in the
publishing function?), but I use something like the following to handle
custom keywords:

,----
| #+MWP_EXPORT_TYPE: slides
|
| #+name: elt
| #+begin_src emacs-lisp :results silent :exports none
| (let ((tree (org-element-parse-buffer)))
|   (org-element-map
|       tree 'keyword
|     (lambda (r)
|       (let ((key (org-element-property :key r))
|             (value (org-element-property :value r)))
|         (when (string= key "MWP_EXPORT_TYPE")
|           value))) ;; Return the keyword value
|     nil t))
| #+end_src
`----

If you have access to the parsed tree or the buffer filename, you may be
able to use this or something similar (maybe wrapped in a function).

Hope it helps.

On 2019-08-02T12:10:18-0400, Matt Price wrote:

  I'm trying to streamline some veyr ad-hoc workflows I have. One thing I do
  a lot during the school year is make some changes to an org source file,
  and then export to hugo markdown with ox-hugo, and finally commit to git
  (after that I have a git hook that generates the website & uploads the
  changed pages to the appropriate location, usually a github-pages branch or
  separate repo).

  So I have this code:

  (defun mwp-hugo-export-and-release ()
    "Make it faster and easier to put my lectures up on the website."
    (interactive)

    (let* ((modfile (org-hugo-export-wim-to-md))
           (basedir (plist-get  (org-export-get-environment 'hugo)
  ':hugo-base-dir ))
           (default-directory (expand-file-name basedir)))
      (magit-stage-file modfile)
      ;; (magit-status)
      (magit-commit-create)
      )  )

  It works great, I'm very happy. HOWEVER: in my websites I have two kinds of
  outputs:

  - regular pages -- these get exported to .md files and turned into html by
  hugo
  - lecture notes -- these get exported to reveal.js HTML pages by
  org-re-reveal and my hugo theme treats them differently .

  I would really like to set a switch somewhere in the file, something like:

  #+MWP_EXPORT_TYPE: slides

  And then something like

  let* ((modfile (if (eq :mwp-export-type "slides")
  (mwp-hugo-reveal-custom-export-function)
                                 (org-hugo-export-wim-to-md)))
       ....etc)
              do stuff)


  But I'm not sure how to get access to a totally non-standard option like
  the kind I just invented in that last bit of pseudo-code. Anyone have a
  good suggestion?

  Thank you as always!

  Matt

Re: getting access to a self-invented option?

[Berry, Charles]

Matt,

This seems like a good use case for a `derived-backend'.

You can use  `org-export-define-derived-backend' with 'hugo as the parent, define a :menu-entry to add an export action for your custom export to the hugo menu using '?m' (say) as the key.

Then 

	C-c C-e H m

will export using your custom variant of hugo.


HTH,

Chuck


> On Aug 2, 2019, at 9:10 AM, Matt Price <moptop99@gmail.com> wrote:
> 
> I'm trying to streamline some veyr ad-hoc workflows I have. One thing I do a lot during the school year is make some changes to an org source file, and then export to hugo markdown with ox-hugo, and finally commit to git (after that I have a git hook that generates the website & uploads the changed pages to the appropriate location, usually a github-pages branch or separate repo). 
> 
> So I have this code:
> 
> (defun mwp-hugo-export-and-release ()
>   "Make it faster and easier to put my lectures up on the website."
>   (interactive)
>   
>   (let* ((modfile (org-hugo-export-wim-to-md))
>          (basedir (plist-get  (org-export-get-environment 'hugo) ':hugo-base-dir ))
>          (default-directory (expand-file-name basedir)))
>     (magit-stage-file modfile)
>     ;; (magit-status)
>     (magit-commit-create)
>     )  )
> 
> It works great, I'm very happy. HOWEVER: in my websites I have two kinds of outputs: 
> 
> - regular pages -- these get exported to .md files and turned into html by hugo
> - lecture notes -- these get exported to reveal.js HTML pages by org-re-reveal and my hugo theme treats them differently .
> 
> I would really like to set a switch somewhere in the file, something like:
> 
> #+MWP_EXPORT_TYPE: slides
> 
> And then something like 
> 
> let* ((modfile (if (eq :mwp-export-type "slides") (mwp-hugo-reveal-custom-export-function)
>                                (org-hugo-export-wim-to-md)))
>      ....etc)
>             do stuff)
> 
> 
> But I'm not sure how to get access to a totally non-standard option like the kind I just invented in that last bit of pseudo-code. Anyone have a good suggestion?
> 
> Thank you as always!
> 
> Matt

Re: getting access to a self-invented option?

[Matt Price]

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

On Sat, Aug 3, 2019 at 1:28 AM Thibault Marin <thibault.marin@gmx.com>
wrote:

> Hi,
>
> I am not sure where you are trying to get to the value (in the
> publishing function?), but I use something like the following to handle
> custom keywords:
>
> ,----
> | #+MWP_EXPORT_TYPE: slides
> |
> | #+name: elt
> | #+begin_src emacs-lisp :results silent :exports none
> | (let ((tree (org-element-parse-buffer)))
> |   (org-element-map
> |       tree 'keyword
> |     (lambda (r)
> |       (let ((key (org-element-property :key r))
> |             (value (org-element-property :value r)))
> |         (when (string= key "MWP_EXPORT_TYPE")
> |           value))) ;; Return the keyword value
> |     nil t))
> | #+end_src
> `----
>
> If you have access to the parsed tree or the buffer filename, you may be
> able to use this or something similar (maybe wrapped in a function).
>
> Hope it helps.
>
>
I think this is a pretty good option -- I would use this in an interactive
function that is called from the org buffer, so I should be able to parse
it. I keep all my lectures in a single file, and same for all my other
course materials, so I guess I will have to do some testing and see how
long the parse operation takes...

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

Re: getting access to a self-invented option?

[Matt Price]

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

On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles <ccberry@ucsd.edu> wrote:

> Matt,
>
> This seems like a good use case for a `derived-backend'.
>
> You can use  `org-export-define-derived-backend' with 'hugo as the parent,
> define a :menu-entry to add an export action for your custom export to the
> hugo menu using '?m' (say) as the key.
>
> Then
>
>         C-c C-e H m
>
> will export using your custom variant of hugo.
>
> :-) I'm trying to use the variable to determine whether I export with hugo
or with my hugo-reveal franken-backend:
https://github.com/titaniumbones/ox-huveal . So my preference is to
evaluate the variable BEFORE export begins.

I guess another option is to just set a buffer-local variable in the file,
or use #+FILETAGS: and hack htings that way. I'm not sure what the most
sustainable & org-like method relaly is...



>
> HTH,
>
> Chuck
>
>
> > On Aug 2, 2019, at 9:10 AM, Matt Price <moptop99@gmail.com> wrote:
> >
> > I'm trying to streamline some veyr ad-hoc workflows I have. One thing I
> do a lot during the school year is make some changes to an org source file,
> and then export to hugo markdown with ox-hugo, and finally commit to git
> (after that I have a git hook that generates the website & uploads the
> changed pages to the appropriate location, usually a github-pages branch or
> separate repo).
> >
> > So I have this code:
> >
> > (defun mwp-hugo-export-and-release ()
> >   "Make it faster and easier to put my lectures up on the website."
> >   (interactive)
> >
> >   (let* ((modfile (org-hugo-export-wim-to-md))
> >          (basedir (plist-get  (org-export-get-environment 'hugo)
> ':hugo-base-dir ))
> >          (default-directory (expand-file-name basedir)))
> >     (magit-stage-file modfile)
> >     ;; (magit-status)
> >     (magit-commit-create)
> >     )  )
> >
> > It works great, I'm very happy. HOWEVER: in my websites I have two kinds
> of outputs:
> >
> > - regular pages -- these get exported to .md files and turned into html
> by hugo
> > - lecture notes -- these get exported to reveal.js HTML pages by
> org-re-reveal and my hugo theme treats them differently .
> >
> > I would really like to set a switch somewhere in the file, something
> like:
> >
> > #+MWP_EXPORT_TYPE: slides
> >
> > And then something like
> >
> > let* ((modfile (if (eq :mwp-export-type "slides")
> (mwp-hugo-reveal-custom-export-function)
> >                                (org-hugo-export-wim-to-md)))
> >      ....etc)
> >             do stuff)
> >
> >
> > But I'm not sure how to get access to a totally non-standard option like
> the kind I just invented in that last bit of pseudo-code. Anyone have a
> good suggestion?
> >
> > Thank you as always!
> >
> > Matt
>
>
>

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

Re: getting access to a self-invented option?

[Matt Price]

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

On Fri, Aug 2, 2019 at 4:02 PM Tim Cross <theophilusx@gmail.com> wrote:

>
> Could you just use a tag for this? My shallow thought is that if you
> tagged headlines, over time you could use different tags for different
> content type whereas if you use a new custom type, you would need to
> repeat the definition process (whatever that might be) every time you
> discovered a new required type. This would also enable you to benefit
> from some of the other nice attributes of tags, such as inheritance.
>

Googling a bit after reading your answer, I fond #+FILETAGS: which I hadn't
noticed before. Since all my lectures are in the same file, I guess I could
just add a single line to that file and, as you say, eventually I'd have an
extensible and potentially more sustainable system.

Thanks to you and everyone else! sorry I too ka while to get back, forgot I
wouldn't have Internet while I was away.

>

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

Re: getting access to a self-invented option?

[Berry, Charles]

Matt,

See inline.

> On Aug 7, 2019, at 8:36 AM, Matt Price <moptop99@gmail.com> wrote
> 
> 
> On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles <ccberry@ucsd.edu> wrote:
> Matt,
> 
> This seems like a good use case for a `derived-backend'.
> 
> You can use  `org-export-define-derived-backend' with 'hugo as the parent, define a :menu-entry to add an export action for your custom export to the hugo menu using '?m' (say) as the key.
> 
> Then 
> 
>         C-c C-e H m
> 
> will export using your custom variant of hugo.
> 
> :-) I'm trying to use the variable to determine whether I export with hugo or with my hugo-reveal franken-backend: https://github.com/titaniumbones/ox-huveal . So my preference is to evaluate the variable BEFORE export begins. 

But `org-export-as' doesn't execute until the dispatcher has run and the choice of hugo or hugo-reveal has been made. 

However, if this determination is permanently set for a particular file (you only export in one manner according to the variable and never alter the variable), then see below.


> 
> I guess another option is to just set a buffer-local variable in the file, or use #+FILETAGS: and hack htings that way. I'm not sure what the most sustainable & org-like method relaly is... 
> 

The obvious choice for a local file setting is an OPTION. Since your 'huveal backend already has an :options-alist, you can just add another option for `:mwp-export-type' there. If you want access to the value before `org-export-as' runs, try something like 

	(plist-get (org-export-get-environment) :mwp-export-type) 


HTH,

Chuck

Re: getting access to a self-invented option?

[Berry, Charles]

Correction below.

[snip]

> 
>> 
>> I guess another option is to just set a buffer-local variable in the file, or use #+FILETAGS: and hack htings that way. I'm not sure what the most sustainable & org-like method relaly is... 
>> 
> 


> The obvious choice for a local file setting is an OPTION. Since your 'huveal backend already has an :options-alist, you can just add another option for `:mwp-export-type' there. If you want access to the value before `org-export-as' runs, try something like 
> 
> 	(plist-get (org-export-get-environment) :mwp-export-type) 


Rather

	(plist-get (org-export-get-environment 'huveal) :mwp-export-type)

is needed to access your custom options before export is underway. 

Chuck