seems like i removed that target at some point and forgot to update the
readme. As installing go is os specific let's just check for go instead and
let the user handle the installing.
hugo is nice - but it's huge. I've never built a static site generator before
and thought the world could use one more - it's not like there's already enough
choice out there!
No, but seriously. I love hugo and it has all the bells and whistles and you
should definitely use that and not this. I just like reinventing the wheel to
learn about stuff - and I like the 80/20 rule. This gives like 60% of what I
want already and is tiny fraction of hugo in terms of LOC (hugo without it's
bazillion dependencies is like 80k+ - this is like 500 and very likely won't
ever grow above let's say 5k).
Also org mode is awesome and why not use it as a configuration format as
well. Let's see where this goes. YOLO.
I never wanted to reproduce the emacs org-export-as-html output exactly but
rather just provide a sensible exporter - the README should tell users what to
expect here.
also dismiss implementing ordered list bullet overrides for now, e.g.
1. [@10] foo
add it once someone needs it - for now it seems like needless complexity
list items only contain content that is indented to their respective
level. Except when that content is inside a block. To allow for this we have to
ignore the parentStop when parsing a block and just include everything until
the end of that block.
Can't think of any problems with this right now. Let's see if this comes
back to bite me.
see https://orgmode.org/manual/Checkboxes.html
We're deviating from Org mode regarding the assigned css classes but the chosen
classes feel better than (on, off, trans) and it's not like the export matches
1:1 otherwise.
Org mode separates kvs not as initially assumed by whitespace (~ csv) but
rather at keywords (~ :\w+).
This is still not replicating Org mode behaviour though as I decided against
attributes ignoring multi-definitions. Instead we stack their
values (and those existing on the element) for certain attributes (class, style
for now).
e.g.
[[foo]]
would become <foo class="a"> in Org mode but becomes <foo class="a b"> with
go-org.
https://scripter.co/how-do-i-write-org-mode/
Prefer “Org mode” to “Org-mode” or “org-mode”. This is simply because it reflects an existing convention in The Emacs Manual which consistently documents mode names in this form - “Text mode”, “Outline mode”, “Mail mode”, etc.
including org files is more complex - e.g. footnotes need to be namespaced to
their source file. org does this by prefixing each included files footnotes
with a number - but even that is not enough as it doesn't guarantee
uniqueness.
As I don't have a usecase for it, I'll avoid the additional complexity for
now.
Also dismissed implementing colgroups for now - had it but didn't like the
added complexity for a very questionable benefit - i've actually never used
that feature of org tables...
- was missing spaces between attributes when rendering to org
- was duplicating attributes when rendering to html - now we join / replace
attributes depending on the name - for now only class & style are appended
I went through the issues of goorgeous and picked a few that seemed easy enough
to add (and added some fore as todos for later). That helped a lot and showed
some bugs / edge cases that required changes.
- the org writer wrote a lot of eol spaces and just removed it whenever
String() was actually called. That worked until now but did not bode with
rendering an empty headline - by removing ALL eol space we would render "* "
back as just "*" -> not a headline anymore.
- the html writer had some special handling for line spacing inside paragraphs
and list items - with the introduction of more blocks we need that handling
everywhere.
As browsers / html renderers are nice enough to collapse whitespace (and
especially collapse "\s*\n" into " ") we can just write out the newlines and
let the renderer take care of the rest.
