This reverts commit 654dba0838.
That commit wasn't the cleanest way to make the HTML valid. Actually
the HTML will never be valid because of the div hack.. I guess we just
live with it till Hugo/Blackfriday adds support for wrapping Markdown
elements in div tags.
Fixes https://github.com/kaushalmodi/ox-hugo/issues/141
Regular page weight setting is same as before:
Manual:
#+hugo_weight: 100
Auto:
#+hugo_weight: auto
Taxonomy weight setting:
Manual:
#+hugo_weight: :tags 100 :categories 100 :series 100
Auto:
#+hugo_weight: :tags auto :categories auto :series auto
Regular page weight and Taxonomy weights together:
#+hugo_weight: 50 :tags 100 :categories 100 :series 100
or if *not* specifying the page weight in the very beginning, use the
:page keyword:
#+hugo_weight: :tags 100 :categories 100 :page 50 :series 100
https://github.com/kaushalmodi/ox-hugo/issues/139
Remove the requirement to suffix such keys with "{}". This is an
improvement over the previous commit
d0a60c5104.
---
The syntax for specifying nested map values custom front-matter is:
Using property drawer (in subtrees):
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :PARENT_KEY '((KEY1 . VAL1) (KEY2 . VAL2) (KEY3 . VAL3) ..)
Using keyword:
#+hugo_custom_front_matter: :PARENT_KEY '((KEY1 . VAL1) (KEY2 . VAL2) (KEY3 . VAL3) ..)
Note that the elements in the list *have to be* dotted-pairs
like (KEY1 . VAL1). That is what tells ox-hugo that this is a nested
map.
Only 1 level of nested keys is supported.
The syntax for specifying nested map values custom front-matter is:
Using property drawer (in subtrees):
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :PARENT_KEY{} '((KEY1 . VAL1) (KEY2 . VAL2) (KEY3 . VAL3) ..)
Using keyword:
#+hugo_custom_front_matter: :PARENT_KEY{} '((KEY1 . VAL1) (KEY2 . VAL2) (KEY3 . VAL3) ..)
The "{}" at the end of the key name is what tells ox-hugo that this is
a nested map.
Only 1 level of nested keys is supported.
Fixes https://github.com/kaushalmodi/ox-hugo/issues/139.
If an attachment path contains "/static/", that attachment is copied
to the site's static/ dir *even in page bundles*.
This allows one to have links to files in the static/ dir as well as
within the bundle dir, in the case of page bundles.
If an attachment path is:
/foo/<BUNDLE_NAME>/bar/baz.png
That attachment is copied to:
<HUGO_BASE_DIR>/content/<SECTION>/<BUNDLE_NAME>/bar/baz.png
i.e. the attachment path *after* "/<BUNDLE_NAME>/" is retained.
Use plist-put and plist-get instead of passing the description value
via a global variable.
To my surprise, the plist-put and plist-get works across functions!
Add new attribute #+ATTR_SHORTCODE: to specify positional arguments
for the shortcode following ":args".
Example:
#+attr_shortcode: warning
#+begin_alert
This is a warning!
#+end_alert
Above exports as (given HUGO_PAIRED_SHORTCODES is set as "%alert"):
{{% alert warning %}}
This is a warning!
{{% /alert %}}
https://github.com/kaushalmodi/ox-hugo/issues/119
---
This commit is a refinement over
74cb3c2ec8:
- It gets rid of the requirement to use ":args" for positional
arguments.
- Removes unnecessary duplicate syntax (use of :class with
attr_html). If someone wants to have the Org document compatible
with more exporters they should simply *not* use
HUGO_PAIRED_SHORTCODE, and instead rely on the default Special
Blocks behavior (wrapping the text with div or HTML5 tags).
Add new attribute #+ATTR_SHORTCODE: to specify positional arguments
for the shortcode following ":args".
Example:
#+attr_shortcode: :args warning
#+begin_alert
This is a warning!
#+end_alert
Above exports as (given HUGO_PAIRED_SHORTCODES is set as "%alert"):
{{% alert warning %}}
This is a warning!
{{% /alert %}}
For re-usability of Org document with ox-html, below will also result
in the exact same ox-hugo export:
#+attr_html: :class warning
#+begin_alert
This is a warning!
#+end_alert
Simply: #+attr_shortcode -> #+attr_html
:args -> :class
https://github.com/kaushalmodi/ox-hugo/issues/119
Also, now the target and rel attr are once again passed on to the
figure shortcode (a better solution to straightaway discarding those
as done in
e92fcf0037).
Those attributes will still be ineffective as the internal figure
shortcode does not recognize those. But this can be fixed if Hugo adds
the support for those, or if a user simply overrides the internal
shortcode with their custom figure shortcode with that support added.
Kaushal Modi