Heh. I write my blog posts in org mode, and have a way to get Pelican[1] to read them. It doesn't support executing Babel source blocks on export - I should probably add that feature to my package.[2]
I used to use org-mode with hugo but it got annoying, I didn't like how I needed to structure my org files, it kind of forced me into some structure. Now I use Zola with Markdown. I'm losing in power but it's so much simpler tbh.
I blog with emacs using the long-abandoned o-blog generator. Anybody have something better? Using the org-mode exporter, with working org-babel and equations and all that. This article doesn't go into the details.
I was in the same boat for many years! Having started using org-mode for my website in 2018 [1] (just add index.org to the path to see the source), it grew into this massive pile of obscure gen and with my limited comfort level with lisp, turned into a scary smelling concoction of dozens of perl/sed/sh scripts that modified the output to fit my needs and have them do something fancy.
But then, really, sat down for about 48 hours on a lonely weekend when everyone was away and wrote a simple static site generator [2] that takes exact same files and produces output that I fully understand e2e, becoming the project I'm most proud of.
There are so many other generators I tried (hugo, jekyll, rails, asciidoctor, org-publish, astro), rolling up your own gives a sense of a stable foundation. Love your website! So clean. One thing that I'm thinking of adding (though I haven't touched my generator that much, I consider it "complete") is the dynamic execution of source code blocks.
I mean that 2000 lines, I assume, is going to only be that many lines because it will have 20-50k lines of dependencies under it.
It’s not a bad idea to understand the software you use. A matter of where you want to spend your time. Learning about the org-mode internals is also a valid choice.
I write my blog (https://lambdaland.org) entirely in Emacs now. It's Hugo, but I use ox-hugo [1] to convert from org-mode to markdown and Hugo converts it to HTML.
What I like about this: everything else I do is in org-mode anyway, so this fits my brain. I also have some nice org-mode tooling to make things like footnotes, margin notes, etc. look really nice.
A little convoluted, sure, but I've seen worse. :-P
This works if your code snippets generate relatively static output. Lately I often need to create animations, often interactive ones. See https://akkartik.name/debugUIs.html, for example.
In my life I've often switched to more manual tools when I notice that the more automated tool causes me to live within certain limitations. Sometimes it has taken me a decade to notice these limitations. Automation matters when I do something tens of times a day. But I publish a blog post once in tens of days. It feels worth some additional work to get a little more control and break out of ruts.
> Any lightweight markup format (like Markdown or ReStructuredText or whatever) allows for embedding code blocks, but Org, through Babel, can run that code on export, and then display the output in the published document, even when the output is a table or an image.
On their website Quarto look just like normal JupyterLab notebook interface. Does it do anything extra?
One advantage of org-babel is, that one can not only to segmented code execution, but one can specify the dependencies of source blocks and thus doesn't have to run them top to bottom or choose how to run them manually. One simply includes blocks by their name in other blocks and everything will run in the specified order. It shouldn't be too hard to build that into IPython Notebooks, but somehow no one has properly done that yet, or it completely bypassed me, while I still worked with ipynbs for years.
I use org mode files, a small build script and git.
The build system just invokes emacs and compiles org documents to HTML, and installs them in /var/www/${site}. I have a git update hook on the server that invokes the build script when I push updates.
Originally I did just rsync over HTML files though, but I like the new setup a lot.
Just started my blog[1] as another way to dogfood Tritium. So far works pretty well. My posts are going to be short and simple but since Docx -> HTML conversion is straightforward, I should have more capability as the product improves as a word processor.
I’m trying to make it a bi-weekly, 1-hour exercise but finding things to write about that might be interesting in a short window is kinda tough.
What’s the recommendation for the simplest blogging setup to say s3? Req: 0 javascript, simple css, absolutely minimal functions for blogs. My ideal is I open a text file on my Mac in vi, type my thoughts and then save and run some script to publish it and it gets the style and date and index entry automatically.
Almost everything I write, from programs to SQL to HTML to email, I do in emacs. I’ve tried to get Teams chat working but it just isn’t reliable so I use a browser for that.
I use Emacs, but not org-mode (or Babel). I feel like tying yourself to {emacs + format} is limiting - the format should be self-justifying - bonus if there is a good mode for Emacs.
Well, it really is. Org-mode is absolutely amazing for anything that can be [even vaguely] expressed in the outline format - anything hierarchical - personal notes, todo-lists, documentation, wiktionary, dictionary and thesaurus entries, comment threads - yes, I read Hackernews and Reddit in Org-mode, file-system entries, plot outlines and story structures, presentation outlines, financial planning and budget breakdowns, travel itineraries and packing lists, maintenance schedules, decision trees, etc.
Even things like .yaml or python files - sometimes converting indent-based stuff to org-mode can give you better perspective of things, because Org-mode has numerous different ways to search and express the data - someone who's never experienced using sparse trees which work like "smart filters" temporarily hiding everything except the parts matching your search, while preserving the hierarchy, may have no idea how great it is - this entire idea of this abstraction.
It only sounds "limiting", in practice - it is supremely flexible system. It makes me really sad that I have not discovered this flexibility sooner in my life.
I've been using Pandoc for my static site, which I also used for my PhD thesis. I wrote pandoc-plot[0] to render figures in documents like the author does, inspired by Matplotlib's plot-directive[1]. I feel like this feature is a must for technical writing, but getting the details right is tricky!
I was a long time org mode user and used babel extensively [1]. It was a marvelous experience, but the market chose markdown. I still drop into org-mode some times for specific features, and the babel integration is still in its own league, but technically there's nothing preventing something similar for markdown.
I pulled some org-babel code to make a code fence evaluator for markdown a while back [2] but haven't found myself needing it that much. So without a need to wrangle reports or run exports, I think it's a 1% feature for text file connoisseurs.
[1] https://ess.r-project.org/ with babel is an experience I find superior to jupyter tools even after all these years
Sure, the market chose Markdown, but this simply led me to the conclusion that the market isn’t worth following. Of course the mismatch creates some friction, but the benefits of org-mode, for me personally, easily outweigh that.
If it’s about wanting to understand your end to end workflow and you don’t mind it being “except for babel” then you could run emacs as a headless daemon and pass through to babel with emacsclient.
It’s a bit inelegant, and lacks the complete purity of “just 2,000 lines of code”. But the sentiment is already drawing lines based on arbitrary gradations in levels of abstraction. So if it improves your workflow to switch away from the rest of emacs’ baroque cathedral of unused functionality, and you want the simplicity of your bespoke engine, just make a handful of those 2,000 lines a wrapper around some i/o through to babel.
After all, it’s turtles all the way down on this sort of thing, at least until you’re staring at circuit diagrams of thinking, “huh, wonder if I can build it all with multi-, no, half adders..”. Further than that and you’ll probably need to learn some advanced metallurgy.
34 comments
[ 8.5 ms ] story [ 449 ms ] thread[1]https://getpelican.com/
[2]https://blog.nawaz.org/posts/2022/Dec/reintroducing-opel-put...
But then, really, sat down for about 48 hours on a lonely weekend when everyone was away and wrote a simple static site generator [2] that takes exact same files and produces output that I fully understand e2e, becoming the project I'm most proud of.
There are so many other generators I tried (hugo, jekyll, rails, asciidoctor, org-publish, astro), rolling up your own gives a sense of a stable foundation. Love your website! So clean. One thing that I'm thinking of adding (though I haven't touched my generator that much, I consider it "complete") is the dynamic execution of source code blocks.
[1] https://sandyuraz.com
[2] https://github.com/thecsw/darkness
It’s not a bad idea to understand the software you use. A matter of where you want to spend your time. Learning about the org-mode internals is also a valid choice.
What I like about this: everything else I do is in org-mode anyway, so this fits my brain. I also have some nice org-mode tooling to make things like footnotes, margin notes, etc. look really nice.
A little convoluted, sure, but I've seen worse. :-P
[1]: https://ox-hugo.scripter.co/
https://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox-html....
The publish front end is in
https://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox.el
and
https://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox-publi...
In my life I've often switched to more manual tools when I notice that the more automated tool causes me to live within certain limitations. Sometimes it has taken me a decade to notice these limitations. Automation matters when I do something tens of times a day. But I publish a blog post once in tens of days. It feels worth some additional work to get a little more control and break out of ruts.
This is what I love about blogging with Quarto.
One advantage of org-babel is, that one can not only to segmented code execution, but one can specify the dependencies of source blocks and thus doesn't have to run them top to bottom or choose how to run them manually. One simply includes blocks by their name in other blocks and everything will run in the specified order. It shouldn't be too hard to build that into IPython Notebooks, but somehow no one has properly done that yet, or it completely bypassed me, while I still worked with ipynbs for years.
write a txt file, scp then let whatever server serve the files.
The build system just invokes emacs and compiles org documents to HTML, and installs them in /var/www/${site}. I have a git update hook on the server that invokes the build script when I push updates.
Originally I did just rsync over HTML files though, but I like the new setup a lot.
More robust than my previous emacs setup and much lighter than hugo. No fancy babel generation but I don’t really need that.
I’m trying to make it a bi-weekly, 1-hour exercise but finding things to write about that might be interesting in a short window is kinda tough.
[1] https://tritium.legal/blog
Well, it really is. Org-mode is absolutely amazing for anything that can be [even vaguely] expressed in the outline format - anything hierarchical - personal notes, todo-lists, documentation, wiktionary, dictionary and thesaurus entries, comment threads - yes, I read Hackernews and Reddit in Org-mode, file-system entries, plot outlines and story structures, presentation outlines, financial planning and budget breakdowns, travel itineraries and packing lists, maintenance schedules, decision trees, etc.
Even things like .yaml or python files - sometimes converting indent-based stuff to org-mode can give you better perspective of things, because Org-mode has numerous different ways to search and express the data - someone who's never experienced using sparse trees which work like "smart filters" temporarily hiding everything except the parts matching your search, while preserving the hierarchy, may have no idea how great it is - this entire idea of this abstraction.
It only sounds "limiting", in practice - it is supremely flexible system. It makes me really sad that I have not discovered this flexibility sooner in my life.
I've been using Pandoc for my static site, which I also used for my PhD thesis. I wrote pandoc-plot[0] to render figures in documents like the author does, inspired by Matplotlib's plot-directive[1]. I feel like this feature is a must for technical writing, but getting the details right is tricky!
[0]: https://github.com/LaurentRDC/pandoc-plot
[1]: https://matplotlib.org/stable/api/sphinxext_plot_directive_a...
I pulled some org-babel code to make a code fence evaluator for markdown a while back [2] but haven't found myself needing it that much. So without a need to wrangle reports or run exports, I think it's a 1% feature for text file connoisseurs.
[1] https://ess.r-project.org/ with babel is an experience I find superior to jupyter tools even after all these years
[2] https://github.com/whacked/emacs-markdown-babel
It’s a bit inelegant, and lacks the complete purity of “just 2,000 lines of code”. But the sentiment is already drawing lines based on arbitrary gradations in levels of abstraction. So if it improves your workflow to switch away from the rest of emacs’ baroque cathedral of unused functionality, and you want the simplicity of your bespoke engine, just make a handful of those 2,000 lines a wrapper around some i/o through to babel.
After all, it’s turtles all the way down on this sort of thing, at least until you’re staring at circuit diagrams of thinking, “huh, wonder if I can build it all with multi-, no, half adders..”. Further than that and you’ll probably need to learn some advanced metallurgy.