Why do I keep seeing people that use #Emacs #OrgMode with an external static website generator, usually Hugo, to make a website? Is there something wrong with the org-publish subsystem that comes with org-mode? It seems to work well to me.
Or maybe there's nothing wrong per se with org-publish, but Hugo is somehow better? I can't really imagine Hugo is more extensible than org-publish, but maybe it's better in some other way?
@sanityinc @oantolin 100% this, I’d switch to org-publish in an instant if there was even half the ecosystem of Hugo.
Hugo is already a niche but org-publish is a niche (emacs) within a niche (org-mode) within a niche (org-publish).
@oantolin I assume this is not snark, but a genuine question :)
So Hugo has a long tradition of generating static sites in a way that gels well with how people would want their websites to look and be generated. Rather large community for such a niche project, too.
Then there's the lure of CI/CD pipelines to auto-generate the website as you edit your repository from anywhere. That ought to be possible with emacs and some scripting, too, but Hugo's CLI is made for that
@hauro @ctietze I hear this "harder to learn Elisp" pretty often and find it surprising. Emacs Lisp is a normal programming language, with numbers, strings, lists, arrays, hashtables, and functions; it supports imperative and functional styles. Don't your CS students already know a language with that description, such as Python? It is true that Emacs Lisp has some features that are uncommon in non-Lisp dynamic languages, like macros and variables with dynamic scope (but those two features might be the full list!). Maybe I've forgotten what it feels like to learn hwo to use those features, but I don't think it was particularly difficult.
I can understand the appeal of a CI/CD workflow to generate a website. Somebody else mentioned it here and it is something I had not considered. And I do know Markdown is very popular. (My website used to written in Markdown and converted to HTML by Pandoc.)
@ctietze It is a genuine question! I thought I had include enough clarifying questions to indicate I was seriously asking.
You say that Hugo "gels well with how people would want their websites to look and be generated". For looks, I think I get it. As for "generated" are you saying people have some expectations of how static site generators are supposed to work and that these are expectations met by Hugo but not by org-publish? What kinds of expectations and why do people have them (prior experience with other static site generators that Hugo is imitating)?
The CI/CD pipeline stuff was also mentioned by @sanityinc, and it is a good point that I had not considered. I can understand why that might be popular.
Hi @oantolin ! In my case is not any better since i just dont know how hard it can be to use the org publish feature. I remember to read some org documentation long time ago it seems to me pretty convoluted to me.
So i cant really tell if its better or not. I just cant compare in a fair way. So not knowing org publish, hugo seems easier to put 5 hours and have something up and running almost out of the box.
Never the less this posts put org pusblish again into the radar. I maybe take a look into it in the future.
@oantolin Well, I haven't used any #staticwebpage generator except my own: #lazyblorg.
The reason why I programmed my own generator was that I could not get the features I wanted to have anywhere else:
- blog posts anywhere I like them: among my tasks/projects/contacts/...
- absolute minimal effort to write a post
- that includes also being able to include images with just mentioning their file name
- navigation via #tags and #TagTrees (combination of different tags - very cool!)
- different types of pages: temporal, persistent, ...
- different Atom #feeds for the users: all articles, just one tag, all articles that combine 2 tags
It just feels "home" to me.
More: https://github.com/novoid/lazyblorg
#orgmode #Emacs #orgdown #staticwebpagegenerator #publicvoit
@publicvoit I think you could have implemented that using org-publish and it probably would have been less work than implementing lazyblorg, but I do know you prefer writing Python to Emacs Lisp, which of course is a valid preference. And while I think using org-publish as a base would have helped a little bit, you definitely would still have had to write a bunch of code: the features you are after don't come with org-publish out of the box.
Let me ask something else: has having to adapt to two different org parsers given you any trouble? Probably not, since you control the dialect of Org recognized by lazyblorg, so any departures from Emacs's Org are just conventions you follow personally anyway (like requiring blank lines to separate some constructs).
@oantolin Maybe. I might have thought about re-using org-publish for parts. Maybe there was too much post-processing which made it easier to be be able to control the whole process.
Re your question: what do you mean by 2 parsers? My own naïve Python parser + pypandoc? It's either/or. So no issue.
Yes, the one empty line between two syntax elements is a result of my naïve parser. It was actually a quick hack that turned out working good enough to that I didn't want to start all over again. 😔
@oantolin Nope.
All previously unknown syntax elements go to pypandoc as a fallback. This is really capable.
So I do handle the most common and/or easiest syntax elements with my own Python code. Lists, AFAIR tables and unknown elements go to pypandoc.
This way, lazyblorg is able to deal with pretty much anything you'll throw at it as long as there is an empty line between two different syntax elements.
@oantolin
I'm with you, with org-publish!
https://marcoxbresciani.codeberg.page/digital-garden.html#garden-my-garden
@oantolin Hugo solves problems like cache busting my CSS that I could also solve with org-publish, but don't have to. It also lets me easily integrate org-originated content with other sources.
It feels dirty, but my attempts to replace it have felt dirtier.
@oantolin I had a Mastodon exporter that spat out Markdown files. I replaced that with a JSON dump, which I can turn into pages with a Hugo content adapter. When I use ox-hugo, I can seamlessly integrate the content written in Org with those other dumps.
Nothing I couldn't do from scratch in Elisp, but Hugo makes a convenient intermediate target.
@oantolin
Ive used Jekyll since 2016.
I don't need html. I don't need to build a site framework or css. I can publish directly as org or MD.
I publish to statichost.eu directly from my repo. It fetches it and builds it and publishes it.
I can also create posts from an entire org file or from a single entry which is what I do.
I use static host.eu because codeberg services in this realm are sketchy, or not recommended, or take away from resources they don't seem to have.
It never occured to me that org publish could create a website as easily as this. How do you do it?
@Zenie You mentioned converting single headings to a blog posts, which is a bit harder to do with org-publish; but if you want to put each blog post in a separate file, this configuration is enough:
(setq org-publish-project-alist
'(("blog"
:base-directory "posts/"
:base-extension "org"
:publishing-directory "public/"
:recursive t
:publishing-function org-html-publish-to-html
:auto-sitemap t)))
With that configuration you can just choose "Publish" from the Org Exporter menu to publish the project called "blog".
I think Org does not come with a function that you can use for a single-heading-->blog-post workflow, you'd have to write your own function to use for the :publishing-function key in place of org-html-publish-to-html. It wouldn't be too hard. (Or you can just put your entire blog in one webpage like I do. :P)
@oantolin
Ah I see. That's essentially what I do. I use publish to write my posts to /posts or wherever they go. I have the usual org publish definitions.
It just happens that publish is writing the markdown into a Jekyll project that then generates a static website.
Org-jekyll, or org-hugo is just an export function for org-publish. Posts get yaml headers created from the org drawers...
Omar Antolín
Stefan Böhringer
Matthieu
Steve Purcell
mrg
Roger Schürch
Zenie
Christian Tietze
Hauro
texaco
Karl Voit 
Marco Bresciani
Ross A. Baker