This post felt like a deja vu, because I had read this earlier back in Nov 2017 :). The HN mods should add the 2017 year to the title. That said, for people who haven't read this post earlier, this post shares some great tips! I like the one about deferring packages using `use-package`.
Because this is an old post, references like Spacemacs are now quite dated. Folks prefer Doom Emacs nowadays (though I don't use either of them).
From your config, I see this[1] overriding `org-hugo-link--headline-anchor-maybe`.
I am following a general Emacs Lisp convention of naming internal-use functions and variables with `--` in the names. Unfortunately, that advice won't do anything with the latest ox-hugo as I replaced that particular internal function with something else in past few months as I was improving the anchoring scheme to support an Org Roam user with linking headings based on UUID.
At that point I had added this documentation on Anchors[2] in ox-hugo manual. If you set `org-hugo-anchor-functions` to nil, or add a dummy function to it that just returns "", it would do the same thing as you are doing in your advice right now (not tested).
*Note that will basically break the ability to refer to other sub headings by UUID, CUSTOM_ID or any other mechanism.*
---
I'd welcome contributions to ox-hugo code, documentation so that it can help other Org Roam users too. Even if it doesn't make it into the repo, having a discussion related to ox-hugo + Org Roam issues/tips+tricks in the ox-hugo Discussions forum will be useful to others.
To me at least, mark, details/summary and description lists are not obscure!
While I don't code in HTML directly, I write the mark-up in Org mode that exports to those.
- My recent blog post where I used mark few times (I have set the mark highlight to be brownish to match my site theme) and also the description lists: https://scripter.co/hugo-modules-getting-started/
- In some other posts, I use details/summary to collapse large code blocks.
Hello, ox-hugo author here. Hugo has the best support of Org Mode as a markup. But Org mode is more than a markup. I ended up facing some limitations with the original Org mode parser used by Hugo and so I developed this exporter. Since then the Org parser used by Hugo got replaced by an even better exporter, but still the points mentioned here apply: https://ox-hugo.scripter.co/doc/why-ox-hugo/
The biggest ones are being able to organize all my posts as subtrees in a single Org file and leverage the Org mode's inbuilt"meta data" inheritance.
Emacs Org Babel is amazing! I also was practicing awk examples from The AWK Programming Book few years back in a similar fashion: https://scripter.co/notes/awk/.
And it's not just awk, there are Org Babel packages available for virtually all the languages!
In all the notes pages above, the result of the code blocks is seen directly in the Emacs buffer when I hit C-c C-c. Then I simply* export all those notes to Markdown and publish them using Hugo.
* Tangent: That's one of the main reasons why I went down the path of developing ox-hugo.
If you begin using tuples with named fields, they will technically be of a different type than anon tuples. To keep it simple, just use anon tuples consistently everywhere.
It's great to see reference to hardware design in this thread.
Not hardware, but I have been using Nim for DPI-C interface with SystemVerilog for quite some time. Few weeks back, I started tinkering with Nim macros, and started working on a project to make the VPI interface more approachable.
This language is kind of a hidden gem that not many people are aware of in the HDL/HVL space.
> I like Org mode, but the syntax highlighting support is not great
I know. That's why I said "I hope Github improves Org mode support at some point." :)
> I have been looking at AsciiDoc
If you like Org mode, you can overcome the Github/etc. Org mode rendering limitations by hosting small static sites for your projects. You may choose to do so by simply exporting Org to HTML using ox-html[1], or even exporting Org to markdown for Hugo (disclaimer: my package -> ox-hugo)[2].
I mean, if you like using Org mode, and Github et al don't see the value in improving support for that, don't use them to render Org mode docs :)
That's grossly incorrect about Nim. I'm a C/C++ noob and I've found a lot of C/C++/Nim/CS experts answering my questions and helping me out on Nim IRC/Gitter/Nim Forums.
Cool write up! I am a huge fan of Nim. I use it as a replacement for small scripts, big scripts, and even real code at work, to interface with other languages that interface with C too.
I see in your post that you are about to look into Nim/C interop; have a look at nimterop[1]. It has been immensely useful to me for wrapping Nim libraries around C code exported from Matlab and to talk with C API for SystemVerilog.
Finally, you blog post shows a snippet of Python code, but also show to the world how the Nim code looks [I know that you are sharing the link to the git repo containing the Nim code, but still] :)
BeetleB already mentioned ox-hugo above. I happened to stumble across this thread (because Org mode!) and I am also the ox-hugo author.
I started working on ox-hugo exactly to have an Org export solution that exports the content + meta-data. If you look at the screenshots on the ox-hugo homepage (linked in BeetleB's comment), you'll see what I mean.
My comment was directed at the incorrect statements that sound like facts that the author made.
I am not saying that people are born knowing how to use Hugo. Hugo is powerful. If you want to tweak it (the theme), change how your site looks and all, you would need to understand how Hugo works, learn templating,etc.
If you are happy with one of the existing templates, you don't need most of that.
Nothing comes for free. You either learn or live with what an existing theme has. I think, this applies, to anything in general.