2
points
kaushalmodi
Joined 353 karma
Loves Emacs and command-line utilities. You can find me by the same username on GitHub, Gitlab, reddit and Twitter.
Blog: https://scripter.co
* Few projects:
- Org-mode + Hugo: https://ox-hugo.scripter.co
- Eless (A Better less): https://eless.scripter.co
- kaushalmodi parentThank you for developing this extension! This makes the pages definitely much more better looking and readable than the Firefox built-in Reader View.
- I kind of agree with that ;)
Nothing beats the speed of Hugo and content creation in Org mode.
- 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).
- You can customize the bindings in logseq. I've customized mine[1] to bring them as close as possible to default Emacs and Org mode bindings.
[1]: https://github.com/kaushalmodi/dotfiles/blob/master/logseq/l...
- > a lot of hacks to get exporting to ox-hugo to work
Hello! Please feel free to start a discussion on https://github.com/kaushalmodi/ox-hugo/discussions listing the things you need to tweak in ox-hugo to make it work with Org Roam.
In the past 3 months or so, I have been adding test Org files received from Org Roam users and they seem to be exporting alright.
Tests: https://github.com/kaushalmodi/ox-hugo/tree/main/test/site/c...
I'd welcome more tests there :)
> and improve performance [your config link]
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.
Thanks!
---
[1]: https://github.com/alexkehayias/emacs.d/blob/3b546048cc60976...
- 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.
- No, having the related executable in the PATH before you start emacs is enough.
Then you need to install the Org Babel packages that don't ship with Emacs or Org mode e.g. ob-tcl, ob-nim.
- Thanks! I've subscribed to this on Pocket Casts: https://pca.st/2Kjz.
- 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!
- Nim (these are my most comprehensive set of notes): https://scripter.co/notes/nim/
- Tcl: https://scripter.co/notes/tcl/
- String formatting in Nim and Python: https://scripter.co/notes/string-fns-nim-vs-python/
- PlantUML: https://scripter.co/notes/plantuml/
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.
- No, I'm happy with them. I've been using them for many years.
- 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.
I have some notes on tuples in Nim: https://scripter.co/notes/nim/#tuples
- 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.
- Hugo has a single static binary. So the site will always generate the same way with the same binary.
- > 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 :)
- So cool to see Org mode READMEs in projects unrelated to Emacs!
I hope Github improves Org mode support at some point.
- > no support, no community, no libraries
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.
Recent (as recent as few hours ago) proof: https://forum.nim-lang.org/t/4912
- 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.
Ask me anything about it.
- 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.
- The post author seems to have not reviewed at least the Hugo docs very well. One clean sign is that he listed "Page Bundles", "Leaf Bundles", index.md and _index.md as "different concepts", when in fact they are all Page Bundles.
Also the author completely missed the point that everything is a "page".
I wish I had time to write a detailed reply to this post but looks like the author has made up his mind to puke on Hugo. I hope this reply serves as a warning that the author's warning about Hugo is very uneducated.
AMA regarding clarification about Hugo in that post.
- I've used EverOrg[0] to convert my evernote files to Org files, retains the attachments (images, PDFs, etc) wonderfully too.
- Can you do a small write-up on that lambda function? I know nothing about those, but I know that Netlify kind of? supports them? If possible I'd like to set up an end point on my Netlify deployed site and do what you are doing. Thanks! :)
- I use Org Babel in Emacs as a "REPL", and an Org Babel package for Nim exists: ob-nim[0], and it's awesome.
For folks uninitiated about Org Babel, it allows one to write small code snippets and quickly evaluate the results and have them inserted below. I keep a nim-scratch.org handy to quickly try out new snippets. Unlike traditional REPL's, this approach allows me to keep on saving new snippets and their results too!
Here's how it looks: https://i.imgtc.com/FAnay93.png
Here's another example: https://i.imgtc.com/xLfiR6p.png. The beauty of this approach is that then I can simply export that my blog[1] (you can correlate 1-1 how that screenshot matches with the content on that blog) :).
- Adding one more "learning resource".. they are basically my notes.. you can see them get advanced as I learn Nim more (they are still getting constantly updated.. I last verified that all the snippets in there work on Nim 0.19.0).
And the notes:
- It's certainly possible! You just need to know which compiler to use. For example, I used musl-gcc to compile a static binary that can run on any 64-bit GNU/Linux type OS.
See my recent post https://scripter.co/nim-deploying-static-binaries/.
Download and run binary to try: https://github.com/kaushalmodi/hello_musl/releases (prints just "Hello, world!").
I plan to release similar binary for my ntodo[0] project, that will make API calls to fetch/set tasks in Todoist.
- Hello, thanks for the detailed reply.
I am not from a software development background (I am kind of (Verilog), but am not much familiar with the best practices of software development). So you comment was quite insightful for me.
>The reason why static linking has been all but banned is security and bug fixes: with static linking, the bugs and performance issues are fused into the resulting binary; fixes to libc will require a complete re-build.
Wouldn't the same apply to the whole binary itself even if it is dynamically linked? What if the app itself has a security bug? Wouldn't the overhead to fix+recompile the statically linked binary be the same as that for dynamically linked?
[Or may be the problem is that the users with the binaries build with buggy musl-gcc need to be aware that there's a security risk, and that they need to download the fixed version I later re-deployed?]
> If you're delivering static binaries for embedded firmware images, this will quickly turn into a security maintenance nightmare, especially for end users of the final product.
Hmm, my goal is to deploy simple CLI apps. Here's an example of one[0] in progress. If someone wants to try this CLI app for Todoist, my goal is that they should be just able to download it and run.
> Linking dynamically with libc will never be an issue on illumos- or any real UNIX-based operating system because libc includes all previous interface versions and can therefore guarantee that it is backward compatible.
Do you know if I to use illumos/OmniOS/SmartOS (this is the first time I am hearing about these) on Travis CI? And how?
> Long story short: develop and build your software on an illumos-based operating system like OmniOS or SmartOS and dynamically link only with libc and you won't have to worry about static linking for convenience delivery: link on the oldest version of SmartOS and sleep well at night knowing your application will work on the latest nightly build.
Thanks! If I can do this on Travis CI (or any other auto-deployment solution via GitHub or even Gitlab), I am willing to give that a try. I am open to suggestions and pointers on how to do that.
> As an added bonus, your binary will be smaller and
+1
> the runtime linker will only mmap(2) the required code pages out of libc into memory.
That part, I did not understand :)
- 7 points
