search

srackham / hindsite

hindsite is a fast, lightweight static website generator.
MIT License
2 stars 2 forks source link

hindsite w/ ox-hugo -- author and date fields #1

Closed reuleaux closed 5 years ago

reuleaux commented 5 years ago

I have tried your static site generator hindsite (thanks for creating this), with ox-hugo for creating .md from .org files, and had to make two changes to the ox-hugo export, to create a toml config that would be accepted by hindsite as well (at the top of an article) , like so:

+++
title = "Projects"
author = "Some Author"
date = "2018-10-22"
draft = false
+++
srackham commented 5 years ago

Thanks for the feedback. This is the first time I have heard of Org (I'm a vi user), it looks interesting.

I had envisaged that multiple authors would be rare and could be accommodated by specifying them in the 'author' variable e.g.

author = "Joe Bloggs and Foo Bar"

So I'm guessing that what you are proposing is that author = ["Some Author"] is processed the same as author = "Some Author".

The Go TOML parser is statically typed and the author field cannot be both an array or a string so accepting both would not be trivial. Introducing as separate 'authors' array variable would be possible but would add to the cognitive overhead and be potentially confusing.

The primary rationale for hindsite is simplicity. I had previously been a casual hugo user. Hugo is very powerful but my use-case was a simple blog and I had become frustrated by hugo's complexity.

I never say never, but for now my preference is to stick with your ox-hugo fix.

On Sun, Oct 28, 2018 at 9:33 PM Andreas Reuleaux notifications@github.com wrote:

I have tried your static site generator hindsite (thanks for creating this), with ox-hugo for creating .md from .org files, and had to make two changes to the ox-hugo export, to create a toml config that would be accepted by hindsite as well (at the top of an article) , like so:

+++ title = "Projects" author = "Some Author" date = "2018-10-22" draft = false +++

-

ox-hugo would produce just ordinary dates out of the box, like so date = 2018-10-22, and I had to tell ox-hugo to wrap the date in double quotes:

(setq org-hugo-date-format "\"%Y-%m-%d\"")

that was easy enough.

ox-hugo would produce a list of authors (even if just one author was given), like so author = ["Some Author"] now I had to dig deeper in ox-hugo and replace

(data `(;; The order of the elements below will be the order in which the front-matter ;; variables will be ordered. (title . ,(org-hugo--sanitize-title info)) (audio . ,(plist-get info :hugo-audio)) (author . ,author-list) ...

with

(data `(;; The order of the elements below will be the order in which the front-matter ;; variables will be ordered. (title . ,(org-hugo--sanitize-title info)) (author . ,(plist-get info :author)) ...

to have it produce author = "Some Author", as required by hindsite.

I wonder, if it would be possible to make hindsite accept author lists (as prduced by ox-hugo) ? It seems possible after all, to have several authors for an article. Thanks in advance

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/srackham/hindsite/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AApKpP0csXdQpAL0vOYSgTTNKiFQmJEqks5upWvkgaJpZM4X92Vs .

reuleaux commented 5 years ago

Thanks for your feedback, and: OK fine, I can live with my ox-hugo fix.

I could in turn ask Kaushal Modi, the author of ox-hugo to have my fix integrated as an option (and maybe he'd even be interested in supporting hindsite), or create ox-hindsite, a fork of ox-hugo. - will see, if this remains my only fix, and I don't have too much time to invest either.

While it is true that org has originated from emacs, it is not tied to emacs per se, cf for example:

https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

and several tools have started to support orgmode:

and when it comes to generating static sites, there are several options for org: for one thing the traditinal publish toolchain, cf for example

https://thibaultmarin.github.io/blog/posts/2016-11-13-Personal_website_in_org.html https://ogbe.net/blog/blogging_with_org.html https://pank.eu/blog/blog-setup.html http://endlessparentheses.com/how-i-blog-one-year-of-posts-in-a-single-org-file.html

(and several more exporters, eg. org-page)

or the ox-hugo approach, bridging the gap between orgmode (as a markup format) and static site generators typically using markdown, by exporting orgmode to blackfriday markdown - and that's what made me curious, when I came accross hindsite: hindsite building upon blackfriday, and I thought ox-hugo could be a fit for hindsite as well.

I certainly like your tool, and I find hugo overwhelming at times, too. Maybe you should make some more advertising for hindsite ? (it seems a one man project currently, right?)

Thanks, -A

Stuart Rackham notifications@github.com writes:

Thanks for the feedback. This is the first time I have heard of Org (I'm a vi user), it looks interesting.

I had envisaged that multiple authors would be rare and could be accommodated by specifying them in the 'author' variable e.g.

author = "Joe Bloggs and Foo Bar"

So I'm guessing that what you are proposing is that author = ["Some Author"] is processed the same as author = "Some Author".

The Go TOML parser is statically typed and the author field cannot be both an array or a string so accepting both would not be trivial. Introducing as separate 'authors' array variable would be possible but would add to the cognitive overhead and be potentially confusing.

The primary rationale for hindsite is simplicity. I had previously been a casual hugo user. Hugo is very powerful but my use-case was a simple blog and I had become frustrated by hugo's complexity.

I never say never, but for now my preference is to stick with your ox-hugo fix.

On Sun, Oct 28, 2018 at 9:33 PM Andreas Reuleaux notifications@github.com wrote:

srackham commented 5 years ago

Thanks for all the information on Org, read the first article and agree with the authors preference for prefix-style headers and he wasn't to hard on the AsciiDoc URL format. Personally, my favourite text markup format is Rimu http://srackham.github.io/rimu/ but I'm biased :-)

Yeah, hindsite is just me. Apart from a brief announcement on Reddit I haven't promoted it. It's not that I don't want lots of users, just that I can't motivate myself to push it, I'd rather do other stuff.

On Mon, Oct 29, 2018 at 2:23 PM Andreas Reuleaux notifications@github.com wrote:

Thanks for your feedback, and: OK fine, I can live with my ox-hugo fix.

I could in turn ask Kaushal Modi, the author of ox-hugo to have my fix integrated as an option (and maybe he'd even be interested in supporting hindsite), or create ox-hindsite, a fork of ox-hugo. - will see, if this remains my only fix, and I don't have too much time to invest either.

While it is true that org has originated from emacs, it is not tied to emacs per se, cf for example:

https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

and several tools have started to support orgmode:

  • pandoc (import + export)

  • hugo supports orgmode natively, but maybe not in the best possible manner, certainly not completely: Kaushal had a reason to avoid it, as I understand (I would have to search for links), and create his own org to markdown exporter instead.

  • github renders org pages (among .adoc, .md etc), with some ruby packages: https://github.com/github/markup, https://github.com/bdewey/org-ruby

and when it comes to generating static sites, there are several options for org: for one thing the traditinal publish toolchain, cf for example

https://thibaultmarin.github.io/blog/posts/2016-11-13-Personal_website_in_org.html https://ogbe.net/blog/blogging_with_org.html https://pank.eu/blog/blog-setup.html

http://endlessparentheses.com/how-i-blog-one-year-of-posts-in-a-single-org-file.html

(and several more exporters, eg. org-page)

or the ox-hugo approach, bridging the gap between orgmode (as a markup format) and static site generators typically using markdown, by exporting orgmode to blackfriday markdown - and that's what made me curious, when I came accross hindsite: hindsite building upon blackfriday, and I thought ox-hugo could be a fit for hindsite as well.

I certainly like your tool, and I find hugo overwhelming at times, too. Maybe you should make some more advertising for hindsite ? (it seems a one man project currently, right?)

Thanks, -A

Stuart Rackham notifications@github.com writes:

Thanks for the feedback. This is the first time I have heard of Org (I'm a vi user), it looks interesting.

I had envisaged that multiple authors would be rare and could be accommodated by specifying them in the 'author' variable e.g.

author = "Joe Bloggs and Foo Bar"

So I'm guessing that what you are proposing is that author = ["Some Author"] is processed the same as author = "Some Author".

The Go TOML parser is statically typed and the author field cannot be both an array or a string so accepting both would not be trivial. Introducing as separate 'authors' array variable would be possible but would add to the cognitive overhead and be potentially confusing.

The primary rationale for hindsite is simplicity. I had previously been a casual hugo user. Hugo is very powerful but my use-case was a simple blog and I had become frustrated by hugo's complexity.

I never say never, but for now my preference is to stick with your ox-hugo fix.

On Sun, Oct 28, 2018 at 9:33 PM Andreas Reuleaux < notifications@github.com> wrote:

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/srackham/hindsite/issues/1#issuecomment-433761868, or mute the thread https://github.com/notifications/unsubscribe-auth/AApKpDuzgPqIg2S6C2UgJ-RBgWBteg61ks5upliYgaJpZM4X92Vs .

kaushalmodi commented 5 years ago

Hello!

About dates and strings

ox-hugo would produce just ordinary dates out of the box, like so date = 2018-10-22, and I had to tell ox-hugo to wrap the date in double quotes:

I prevent double-quoting the dates because I want the dates to be parsed as TOML date types and not as plain strings.

@srackham Do you parse dates as "strings" too? If so, doesn't that take away the auto-validity check of dates? Why not just parse them as TOML dates? (Hugo does that)

@reuleaux If hindsite needs dates to be strings, then the workaround you have is the best solution.

About author and authors

@srackham

The Go TOML parser is statically typed and the author field cannot be both an array or a string so accepting both would not be trivial.

Shouldn't it be simple enough to have the internal representation to be a slice of strings, and you have a condition that populates that different based on if author is a TOML string or an array of strings?

I use this in my theme's Go template to allow author to be either a string or an array:

{{ with .page.Params.author }}
    {{ $author_type := (printf "%T" .) }}
    {{ $author_is_slice := (eq "[]string" $author_type) }}
    {{ if $author_is_slice }}
        {{ $author = . }}
    {{ else }}
        {{ $author = (slice .) }}
    {{ end }}
{{ end }}

Can you mimic that in hindsite?

Also:

Introducing as separate 'authors' array variable would be possible but would add to the cognitive overhead and be potentially confusing.

I agree with that. So I stuck with one "author" front-matter param to match Org mode's #+author:. Users are free to add one or more authors to that same keyword and the outcome will be a TOML array with one or more elements.

@reuleaux

ox-hugo would produce a list of authors (even if just one author was given), like so author = ["Some Author"] now I had to dig deeper in ox-hugo and replace ..

If hindsite supporting author arrays doesn't work out, have you looked at https://ox-hugo.scripter.co/doc/author/#forcing-author-to-be-a-string--alternative ?

I had become frustrated by hugo's complexity.

If you don't mind, what was the most frustrating part (I am not a web dev, and I use just the simple Hugo features I need, without the complex features (sass, etc.) bothering me)?

@reuleaux

I could in turn ask Kaushal Modi, the author of ox-hugo to have my fix integrated as an option

Those are not actually fixes.. may be hindsite needs to simply support TOML date types? And the second complicated hack for author might not be needed at all (ref: my reply above).

(and maybe he'd even be interested in supporting hindsite)

I wouldn't be surprised if ox-hugo didn't work "out of the box" for some features that need Hugo; e.g. {{ figure }} and {{ highlight }} shortcodes come to mind.

, or create ox-hindsite, a fork of ox-hugo. - will see, if this remains my only fix, and I don't have too much time to invest either.

I don't use hindsite. So it wouldn't be very time efficient for me to do that.

You can of course do that. You should be able to use ox-blackfriday 100% as it is, and remove/replace Hugo-specific stuff from ox-hugo. As you might already have realized, most of ox-hugo is Org meta data to TOML/YAML translation. So a major part of that should be hindsite-compatible too.

hugo supports orgmode natively, but maybe not in the best possible manner, certainly not completely: Kaushal had a reason to avoid it, as I understand (I would have to search for links), and create his own org to markdown exporter instead.

The Go Org mode parser used by Hugo doesn't support 100% Org syntax, and also its development has stagnated for the past year or so (no response on issue tracker, etc.).

This doesn't cover 100% of the reasons why ox-hugo is a major improvement over Go Org parsing, but here it is: https://ox-hugo.scripter.co/doc/why-ox-hugo/.

when I came accross hindsite: hindsite building upon blackfriday, and I thought ox-hugo could be a fit for hindsite as well.

ox-hugo's job is to convert Org meta data to TOML/YAML front-matter + making the generated markdown Blackfriday v1.0 compatible (because Hugo still uses v1.0). In addition, it exports few Org blocks as Hugo {{ figure }} and {{ highlight }} shortcodes when appropriate. So, in essence, ox-hugo should do most of the work for you to make the Markdown exports hindsite compatible.

I find hugo overwhelming at times, too.

I would like to know what those overwhelming things were, and may be I can help alleviate those by improving the Hugo docs.

srackham commented 5 years ago

Thank you for your detailed critique.

Do you parse dates as "strings" too? If so, doesn't that take away the auto-validity check of dates? Why not just parse them as TOML dates? (Hugo does that)

Yes the dates are parsed as strings, validity is checked at string to date conversion. It does make sense to parse them as dates like Hugo, off the top of my head I don't know why I didn't. I'll put this on my todo list.

Shouldn't it be simple enough to have the internal representation to be a slice of strings, and you have a condition that populates that different based on if author is a TOML string or an array of strings?

Yes probably simple, but not trivial, I'm just not yet convinced the game is worth the candle. As it stands if you want multiple authors you can do e.g.

author = "Jules Verne and Alexandre Dumas"

I guess the real issue is compatibility. Then the question becomes how do we map an author array to an author string e.g.

["Jules Verne","Alexandre Dumas"] => "Jules Verne and Alexandre Dumas" is language specific; ["Jules Verne","Alexandre Dumas"] => "Jules Verne, Alexandre Dumas" won't suit everyone.

On Tue, Oct 30, 2018 at 5:06 PM Kaushal Modi notifications@github.com wrote:

Hello! About dates and strings

ox-hugo would produce just ordinary dates out of the box, like so date = 2018-10-22, and I had to tell ox-hugo to wrap the date in double quotes:

I prevent double-quoting the dates because I want the dates to be parsed as TOML date types and not as plain strings.

@srackham https://github.com/srackham Do you parse dates as "strings" too? If so, doesn't that take away the auto-validity check of dates? Why not just parse them as TOML dates? (Hugo does that)

@reuleaux https://github.com/reuleaux If hindsite needs dates to be strings, then the workaround you have is the best solution. About author and authors

@srackham https://github.com/srackham

The Go TOML parser is statically typed and the author field cannot be both an array or a string so accepting both would not be trivial.

Shouldn't it be simple enough to have the internal representation to be a slice of strings, and you have a condition that populates that different based on if author is a TOML string or an array of strings?

I use this in my theme's Go template to allow author to be either a string or an array:

{{ with .page.Params.author }} {{ $author_type := (printf "%T" .) }} {{ $author_is_slice := (eq "[]string" $author_type) }} {{ if $author_is_slice }} {{ $author = . }} {{ else }} {{ $author = (slice .) }} {{ end }} {{ end }}

Can you mimic that in hindsite?

Also:

Introducing as separate 'authors' array variable would be possible but would add to the cognitive overhead and be potentially confusing.

I agree with that. So I stuck with one "author" front-matter param to match Org mode's #+author:. Users are free to add one or more authors to that same keyword and the outcome will be a TOML array with one or more elements.

@reuleaux https://github.com/reuleaux

ox-hugo would produce a list of authors (even if just one author was given), like so author = ["Some Author"] now I had to dig deeper in ox-hugo and replace ..

If hindsite supporting author arrays doesn't work out, have you looked at https://ox-hugo.scripter.co/doc/author/#forcing-author-to-be-a-string--alternative ?

I had become frustrated by hugo's complexity.

If you don't mind, what was the most frustrating part (I am not a web dev, and I use just the simple Hugo features I need, without the complex features (sass, etc.) bothering me)?

@reuleaux https://github.com/reuleaux

I could in turn ask Kaushal Modi, the author of ox-hugo to have my fix integrated as an option

Those are not actually fixes.. may be hindsite needs to simply support TOML date types? And the second complicated hack for author might not be needed at all (ref: my reply above).

(and maybe he'd even be interested in supporting hindsite)

I wouldn't be surprised if ox-hugo didn't work "out of the box" for some features that need Hugo; e.g. {{ figure }} and {{ highlight }} shortcodes come to mind.

, or create ox-hindsite, a fork of ox-hugo. - will see, if this remains my only fix, and I don't have too much time to invest either.

I don't use hindsite. So it wouldn't be very time efficient for me to do that.

You can of course do that. You should be able to use ox-blackfriday 100% as it is, and remove/replace Hugo-specific stuff from ox-hugo. As you might already have realized, most of ox-hugo is Org meta data to TOML/YAML translation. So a major part of that should be hindsite-compatible too.

hugo supports orgmode natively, but maybe not in the best possible manner, certainly not completely: Kaushal had a reason to avoid it, as I understand (I would have to search for links), and create his own org to markdown exporter instead.

The Go Org mode parser used by Hugo doesn't support 100% Org syntax, and also its development has stagnated for the past year or so (no response on issue tracker, etc.).

This doesn't cover 100% of the reasons why ox-hugo is a major improvement over Go Org parsing, but here it is: https://ox-hugo.scripter.co/doc/why-ox-hugo/.

when I came accross hindsite: hindsite building upon blackfriday, and I thought ox-hugo could be a fit for hindsite as well.

ox-hugo's job is to convert Org meta data to TOML/YAML front-matter + making the generated markdown Blackfriday v1.0 compatible (because Hugo still uses v1.0). In addition, it exports few Org blocks as Hugo {{ figure }} and {{ highlight }} shortcodes when appropriate. So, in essence, ox-hugo should do most of the work for you to make the Markdown exports hindsite compatible.

I find hugo overwhelming at times, too.

I would like to know what those overwhelming things were, and may be I can help alleviate those by improving the Hugo docs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/srackham/hindsite/issues/1#issuecomment-434164900, or mute the thread https://github.com/notifications/unsubscribe-auth/AApKpFGu8IYjMEPgR7fGgcUEePk5tO2Oks5up9BWgaJpZM4X92Vs .

kaushalmodi commented 5 years ago

As it stands if you want multiple authors you can do e.g. author = "Jules Verne and Alexandre Dumas"

That results in hardcoding "language" with meta data. I treat "author" front-matter as data, so mixing language like "and" in there doesn't look right.

You also lose the ability (or make it really difficult) to "do more" with that author data. E.g. if you want to loop through all authors and hyperlink them, you cannot do that if it has language in there.

Blending language in authors manually also introduces inconsistency: "Foo and Bar", "Foo, Bar" (both of those have the same 2 authors but is written in different ways).

On the other side, if author is just a slice (always), it's trivial to add language to it in user templates, and that will happen consistently.

Then the question becomes how do we map an author array to an author string e.g. ["Jules Verne","Alexandre Dumas"] => "Jules Verne and Alexandre Dumas" is language specific; ["Jules Verne","Alexandre Dumas"] => "Jules Verne, Alexandre Dumas" won't suit everyone.

It's not clear to me why hindsite needs to worry about that. Wouldn't the user deal with that in their templates? I was assuming all along that hindsite users can use the Go templates as we do in Hugo.

reuleaux commented 5 years ago

Kaushal, Stuart,

thanks to both of you for your detailed feedback (and I can certainly live with any decision of yours, how to handle dates, authors etc.)

I had come accross hindsite by accident (some search of mine for hugo docs/tutorials/examples being pointed to Stuart's blog, if I remember right: https://blog.srackham.com/about.html, "ported [...] from Hugo to hindsite" as he writes), had given it a try. - and had been pleasently surprised: similar to hugo, but simpler (just templates, no themes, no bundles etc.)

@kaushal Please excuse me, though: I didn't want to come accross as ignorant, or disappointed from hugo. - I guess, I just haven't given it enough time, have tried some things hugo in a hurry more or less (being busy with other things), and have learned other bits by accident, rather than by following any particular tutorial / set of instructions.

The one thing that I wished existed for hugo: a longer indepth tutorial/book, as a pdf or on paper: not a reference, but a series of examples, in increasing order of difficulty, building upon each other perhaps.

I would rather want a longer tutorial/book, that I can put under my pillow, and read in a couple of evenings. - For example: I have learned about list and single templates from one (video) tutorial, and about baseof from another one, which seems less than ideal to me. (And a good understanding of list/single/baseof templates seems more important to me than choosing a theme of my liking, as suggested by many of the blog posts/tutorials). But I think this concern of mine has been raised before: https://discourse.gohugo.io/t/hugo-documentation-in-one-long-searchable-page/238/4 https://github.com/hamoid/long-hugo-doc etc. I own Brian Rinaldi and Raymond Camden's book "Working with Static Sites", but it covers hugo in one chapter only (not really in-depth).

Thanks again, Andreas

kaushalmodi commented 5 years ago

The one thing that I wished existed for hugo

Can you post your comments related to Hugo in https://discourse.gohugo.io/? I won't want to pollute this hindsite related issue.

reuleaux commented 5 years ago

Kaushal Modi notifications@github.com writes:

OK, will do so - not now, but in the future in any case

Thanks, -A

The one thing that I wished existed for hugo

Can you post your comments related to Hugo in https://discourse.gohugo.io/? I won't want to pollute this hindsite related issue.

srackham commented 5 years ago

It's not clear to me why hindsite needs to worry about that. Wouldn't the user deal with that in their templates?

Dealing with it in templates (e.g. your previous example) assumes more than just a cursory knowledge of Go templates and some knowledge of the Go language. The primary goal of hindsite is ease of use and learning e.g. most template variables are strings. This is why I resist additional complexity for the sake of marginal use cases.

On Thu, Nov 1, 2018 at 12:28 AM Kaushal Modi notifications@github.com wrote:

As it stands if you want multiple authors you can do e.g. author = "Jules Verne and Alexandre Dumas"

That results in hardcoding "language" with meta data. I treat "author" front-matter as data, so mixing language like "and" in there doesn't look right.

You also lose the ability (or make it really difficult) to "do more" with that author data. E.g. if you want to loop through all authors and hyperlink them, you cannot do that if it has language in there.

Blending language in authors manually also introduces inconsistency: "Foo and Bar", "Foo, Bar" (both of those have the same 2 authors but is written in different ways).

On the other side, if author is just a slice (always), it's trivial to add language to it in user templates, and that will happen consistently.

Then the question becomes how do we map an author array to an author string e.g. ["Jules Verne","Alexandre Dumas"] => "Jules Verne and Alexandre Dumas" is language specific; ["Jules Verne","Alexandre Dumas"] => "Jules Verne, Alexandre Dumas" won't suit everyone.

It's not clear to me why hindsite needs to worry about that. Wouldn't the user deal with that in their templates? I was assuming all along that hindsite users can use the Go templates as we do in Hugo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/srackham/hindsite/issues/1#issuecomment-434652537, or mute the thread https://github.com/notifications/unsubscribe-auth/AApKpGj8Xogsuc2FNVye8kDIoePmSPzVks5uqYl1gaJpZM4X92Vs .

srackham commented 5 years ago

If you don't mind, what was the most frustrating part?

If I could just chip in with my 2 cents worth.

Hugo is an outstanding program, it's chock full of features and has the flexibility needed to build complex static web sites. But features and flexibility come at the price of complexity and a steeper learning curve.

My frustration was not with hugo but with my brain's ability to retain hard won working knowledge of hugo across 6 months or more between casual use. The relearning necessitated by my occasional reconfiguration and theme tweak is what motivated me to write hindsite. Hindsite was not designed to compete with hugo's full feature set.

On Thu, Nov 1, 2018 at 3:07 AM Andreas Reuleaux notifications@github.com wrote:

Kaushal, Stuart,

thanks to both of you for your detailed feedback (and I can certainly live with any decision of yours, how to handle dates, authors etc.)

I had come accross hindsite by accident (some search of mine for hugo docs/tutorials/examples being pointed to Stuart's blog, if I remember right: https://blog.srackham.com/about.html, "ported [...] from Hugo to hindsite" as he writes), had given it a try. - and had been pleasently surprised: similar to hugo, but simpler (just templates, no themes, no bundles etc.)

@kaushal Please excuse me, though: I didn't want to come accross as ignorant, or disappointed from hugo. - I guess, I just haven't given it enough time, have tried some things hugo in a hurry more or less (being busy with other things), and have learned other bits by accident, rather than by following any particular tutorial / set of instructions.

The one thing that I wished existed for hugo: a longer indepth tutorial/book, as a pdf or on paper: not a reference, but a series of examples, in increasing order of difficulty, building upon each other perhaps.

  • It appears to me, that there are lots of little tutorials (on https://gohugo.io/documentation/ eg., individual blog posts, even videos), that each cover

  • either basic installation steps ("get started", "in 30 mins" etc)

  • or one particular aspect of hugo.

I would rather want a longer tutorial/book, that I can put under my pillow, and read in a couple of evenings. - For example: I have learned about list and single templates from one (video) tutorial, and about baseof from another one, which seems less than ideal to me. (And a good understanding of list/single/baseof templates seems more important to me than choosing a theme of my liking, as suggested by many of the blog posts/tutorials). But I think this concern of mine has been raised before:

https://discourse.gohugo.io/t/hugo-documentation-in-one-long-searchable-page/238/4 https://github.com/hamoid/long-hugo-doc etc. I own Brian Rinaldi and Raymond Camden's book "Working with Static Sites", but it covers hugo in one chapter only (not really in-depth).

Thanks again, Andreas

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/srackham/hindsite/issues/1#issuecomment-434700511, or mute the thread https://github.com/notifications/unsubscribe-auth/AApKpP-Y9ebdP3Tj1c-zfXbRKcAXj_z0ks5uqa6ggaJpZM4X92Vs .

srackham commented 5 years ago

hindsite version 1.3.0 has been released, it allows unquoted date/time front matter date values in TOML headers. The author value remains a string value.