Re: [O] getting access to a self-invented option?
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
Re: [O] getting access to a self-invented option?
Matt, See inline. > On Aug 7, 2019, at 8:36 AM, Matt Price wrote > > > On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles 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: [O] getting access to a self-invented option?
On Fri, Aug 2, 2019 at 4:02 PM Tim Cross 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. >
Re: [O] getting access to a self-invented option?
On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles 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 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: [O] getting access to a self-invented option?
On Sat, Aug 3, 2019 at 1:28 AM Thibault Marin 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...
Re: [O] getting access to a self-invented option?
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 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: [O] getting access to a self-invented option?
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: [O] getting access to a self-invented option?
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 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
[O] getting access to a self-invented option?
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
