I used Hugo's native `.org` file support for a while. It was… fine. There are some serious issues (for me) that I had with it though. The most salient one is that it didn't convert straight quotes in the source ("") to proper curly-quotes. (“”) I don't remember what else but I'm sure there was more than just that. I've spent a lot of time on the typography of my site and I wanted everything to be as perfect as I could make it.
I started using Hugo's built-in org support, but I found it quite limiting. I can't remember the specifics, but it doesn't support everything you can do with Markdown. So I quickly switched to ox-hugo. They can co-exist though so you can try the native support then switch if you run into the same shortcomings as I did.
Perhaps we have dozens of intelligences, with varying degrees of cognition? What is actually happening when the amygdala takes over the nervous system to avoid a car accident before you are aware what is happening? What is really going on with Tourette syndrome?
Might the human gut have its own hopes and dreams?
The way I did it was by not using it for my entire workflow right away. The trojan horse for me was org-mode. Doom Emacs got me started in what felt to be a more modern UX, and I used org-mode not for coding outright, but for note taking and personal project management. After a while, I started to use org-mode's built in ability to run code via org-babel to experiment with ideas in code. Eventually I was comfortable enough that I just started using it to code some times instead of VS Code, because I was already there. I still dual-use VS Code and Emacs because VS Code is still better at some things (working with files on remote server is still kinda slow via TRAMP some times) but I'm about 85% in Emacs now, since I like it better for text traversal, org-mode has become more integrated into my workflow with things like tangle, and I like magit better than VS Code's built-in git interface.
TRAMP is generally performant enough with vanilla Emacs, but there are plenty of popular packages that utterly tank TRAMP performance. The big culprit I’ve personally found was helm. It made TRAMP unusable. You may also need to deal with some finnicky settings both in Emacs and in your remote shell to get it running satisfactorily.
I totally agree though that VS Code has a way better out or the box remote coding experience.
You can use the TTY emacs over SSH (or MOSH) without TRAMP. It only transmits the terminal display so it’s fast regardless of third-party extensions. VS Code remote is actually a negative for me, as it needs fast, stable connections and consumes a lot of RAM on the remote machine.
In case helpful, select the app on the task bar and use Shift+Win+Left/Right arrow key to move it between monitors without needing to do the IKVM dance
What happens when the Sinology dies? Do I have to buy another Synology to mount my array again? Does it have to be the same model, or family of models?
I haven't tested it on Synology, but at least on ASUSTOR, the RAID arrays are set up using mdadm internally—so I was able to pull the drives, plug them into a Pi through a SATA card, and recover the array pretty easily using mdadm.
The vendor NASes do seem to add extra partitions besides just one main 'md0', though—so you probably couldn't expect to yank the drives from a Synology and pop them into an ASUSTOR directly.
I also tested pulling drives configured in the Drivestor and putting them in the Lockerstor, and that worked, but there were quirks if I tried in the opposite direction.
In the end, I would rather make sure I have a complete/separate backup of the NAS before attempting to move the drives, just in case.
I haven't tried pulling one of the drives from my system and trying to read it with another box but I imagine just about any Linux system should be able to read BTRFS drives, no? Under the covers Synology's DSM is Linux with some proprietary apps on top.
Yeah I know at least ASUSTOR's ADM and Synology's DSM are both basically lightweight Linux distros (usually on an older kernel than what you'd expect building something custom), and they use standard Linux storage tooling (for mdadm RAID or btrfs).
I use yabai without disabling sip. You get most of the features. It's the first tiling WM I've used, so it's possible I'm missing something critical without disabling sip, but so far I'm quite happy with it despite whatever features are missing. ymmv, of course.
I suspect it'd be easier to set up a more robust DOOM Emacs inside WSL than native Windows (which the DOOM docs advise is somewhat unadvised), and the GUI version fo Emacs provides some features the CLI version doesn't have.
Yes, I already run Emacs (Spacemacs, to be specific) under WSL2 with X410 as the X Server. Presumably, I'll be able to ditch X410 when this layer gets to my corporate-mandated Windows build.
