emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* getting access to a self-invented option?
@ 2019-08-02 16:10 Matt Price
  2019-08-02 20:00 ` Tim Cross
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Matt Price @ 2019-08-02 16:10 UTC (permalink / raw)
  To: Org Mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-02 16:10 getting access to a self-invented option? Matt Price
@ 2019-08-02 20:00 ` Tim Cross
  2019-08-07 15:39   ` Matt Price
  2019-08-03  5:28 ` Thibault Marin
  2019-08-03 17:42 ` Berry, Charles
  2 siblings, 1 reply; 9+ messages in thread
From: Tim Cross @ 2019-08-02 20:00 UTC (permalink / raw)
  To: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-02 16:10 getting access to a self-invented option? Matt Price
  2019-08-02 20:00 ` Tim Cross
@ 2019-08-03  5:28 ` Thibault Marin
  2019-08-07 15:30   ` Matt Price
  2019-08-03 17:42 ` Berry, Charles
  2 siblings, 1 reply; 9+ messages in thread
From: Thibault Marin @ 2019-08-03  5:28 UTC (permalink / raw)
  To: Matt Price; +Cc: Org Mode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-02 16:10 getting access to a self-invented option? Matt Price
  2019-08-02 20:00 ` Tim Cross
  2019-08-03  5:28 ` Thibault Marin
@ 2019-08-03 17:42 ` Berry, Charles
  2019-08-07 15:36   ` Matt Price
  2 siblings, 1 reply; 9+ messages in thread
From: Berry, Charles @ 2019-08-03 17:42 UTC (permalink / raw)
  To: Matt Price; +Cc: Org Mode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-03  5:28 ` Thibault Marin
@ 2019-08-07 15:30   ` Matt Price
  0 siblings, 0 replies; 9+ messages in thread
From: Matt Price @ 2019-08-07 15:30 UTC (permalink / raw)
  To: thibault.marin, Org Mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-03 17:42 ` Berry, Charles
@ 2019-08-07 15:36   ` Matt Price
  2019-08-07 16:58     ` Berry, Charles
  0 siblings, 1 reply; 9+ messages in thread
From: Matt Price @ 2019-08-07 15:36 UTC (permalink / raw)
  To: Berry, Charles; +Cc: Org Mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-02 20:00 ` Tim Cross
@ 2019-08-07 15:39   ` Matt Price
  0 siblings, 0 replies; 9+ messages in thread
From: Matt Price @ 2019-08-07 15:39 UTC (permalink / raw)
  To: Tim Cross; +Cc: Org Mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-07 15:36   ` Matt Price
@ 2019-08-07 16:58     ` Berry, Charles
  2019-08-07 17:21       ` Berry, Charles
  0 siblings, 1 reply; 9+ messages in thread
From: Berry, Charles @ 2019-08-07 16:58 UTC (permalink / raw)
  To: Matt Price; +Cc: Org Mode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: getting access to a self-invented option?
  2019-08-07 16:58     ` Berry, Charles
@ 2019-08-07 17:21       ` Berry, Charles
  0 siblings, 0 replies; 9+ messages in thread
From: Berry, Charles @ 2019-08-07 17:21 UTC (permalink / raw)
  To: Berry, Charles; +Cc: Org Mode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-08-07 17:22 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-02 16:10 getting access to a self-invented option? Matt Price
2019-08-02 20:00 ` Tim Cross
2019-08-07 15:39   ` Matt Price
2019-08-03  5:28 ` Thibault Marin
2019-08-07 15:30   ` Matt Price
2019-08-03 17:42 ` Berry, Charles
2019-08-07 15:36   ` Matt Price
2019-08-07 16:58     ` Berry, Charles
2019-08-07 17:21       ` Berry, Charles

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).