DEV Community: Edmund Miller

Setting up Doom Emacs for Astro Development

Edmund Miller — Tue, 23 Apr 2024 13:00:00 +0000

Astro is the new hot new web framework on the block. All the cool kids are using it. I've recently given up, drank the Kool-Aid, and gone all in on it.

I've rewritten this website, my partner's website, my university rugby club's website. I'm moving my Applied Genomics course website to Starlight, the Astro team's documentation framework. The nf-core site has been rewritten in Astro and Svelte from PHP. I'm all in.

The beauty of Astro is it's the Nextflow of web frameworks.¹ It allows you to wrap other UI Frameworks in a web framework rather than forcing you to pick one, so you don't just have to pick React, Vue, or Svelte. You can have them all in the same application. You can just use HTML components. That's the beauty. That's why it's exciting. That's why I think it'll stick around.

So anyways, I wanted to hook up Emacs with Astro support. For now, I've just been roughing it out there and running Prettier by itself and turning off save on format and auto-complete. It's been scary.

What I'm seeking from Emacs is multifaceted: Tree-sitter support, LSP (Language Server Protocol) support—to alert me of any missteps—and a fully functional formatter. A frustrating hour was lost to Prettier mangling my Astro templates by wrapping them in quotes—a bug I could have done without. And while we're at it, add Tailwind CSS LSP support into the mix for good measure.

Astro Tree-sitter Support

Tree-sitter is an incremental parsing system for programming tools.
Find out more about it on the project's website!

As the old saying goes, there's an Emacs package for everything. So, of course, someone's already written one for Astro and Tree-sitter.

Setup for astro-ts-mode appears simple:

(package! astro-ts-mode)

(use-package! astro-ts-mode
  :after treesit-auto)

But wait, there's more!

Because this major mode is powered by Tree-sitter, it depends on an external grammar to provide a syntax tree for Astro templates. To set it up, you’ll need to set treesit-language-source-alist to point to the correct repositories for each language.

You can choose to set it up and run treesit-install-language-grammar for astro tsx and css.

Or you can take the red pill and use treesit-auto and automatically install the language grammar.

In case this your first Edmund experience, two things you should know. I love to automate things, and I love a good rabbit hole.

treesit-auto

There was a tip from Ian S. Pringle(Who owns both a farm and a digital garden!).

Ruby Juric(the author of astro-ts-mode) converted the snippet to use let to avoid creating a global variable.

(use-package! astro-ts-mode
  :config
  (global-treesit-auto-mode)
  (let ((astro-recipe (make-treesit-auto-recipe
                       :lang 'astro
                       :ts-mode 'astro-ts-mode
                       :url "https://github.com/virchau13/tree-sitter-astro"
                       :revision "master"
                       :source-dir "src")))
    (add-to-list 'treesit-auto-recipe-list astro-recipe)))

I think this worked for me. I had built it manually with treesit-auto before.

Oh, by the way

!NOTE
Make sure you have a working C compiler as cc in your PATH, since this needs to compile the grammars.

Emacs lsp-mode and Astro Language-server

The official Astro editor docs link to an article with instructions to configure eglot, but there's no equivalent one for lsp-mode.

npm i -g @astrojs/language-server

I just had to add a hook to astro-ts-mode and it pulled right up.

(use-package! astro-ts-mode
  :after treesit-auto
  :init
  (when (modulep! +lsp)
    (add-hook 'astro-ts-mode-hook #'lsp! 'append))
  :config
;; ...

`prettier-plugin-astro` in Emacs with Apheleia

From Sorixelle's Emacs config I found the magic snippet that had prettier use --parser=astro in .astro files. ✨

(set-formatter! 'prettier-astro
  '("npx" "prettier" "--parser=astro"
    (apheleia-formatters-indent "--use-tabs" "--tab-width" 'astro-ts-mode-indent-offset))
  :modes '(astro-ts-mode))

Tailwind CSS IntelliSense in Emacs

Of course, there's already a package for TailwindCSS using LSP. With Doom Emacs installation instructions as well!

(use-package! lsp-tailwindcss
  :when (modulep! +lsp)
  :init

  (setq! lsp-tailwindcss-add-on-mode t)
  :config

  (add-to-list 'lsp-tailwindcss-major-modes 'astro-ts-mode))

Conclusion

You can find all of the code in my Doom Emacs config. It's got everything, Tree-sitter, LSP, Prettier, and Tailwind CSS IntelliSense.

Did I really just compare a very niche DSL to describe a niche programming language? ↩

Using age with org-journal

Edmund Miller — Fri, 15 Dec 2023 19:04:51 +0000

The problem

Because gpg 2.4.1 borked Emacs's EasyPG. It just hangs on saving.

Why not just use gpg?

There are some ways around it, and I was using the fset hack until I read this post about the person who corrupted their encrypted files. I also had to run the elisp on every new Emacs instance.

And then lib-gcrypt is marked as broken in NixOS if you use the gnupg22 package(Version: 2.2.41), and a blowing past that stop sign sounded like a bad idea.

So I started thinking outside the box.

Why age?

I started using it with agenix, just because Henrik started using it in his dotfiles. The k8s@home template also eventually switched from gpg to age so I was already pretty comfortable with using age.

TL;DR Age: the modern alternative to GPG — nixFAQ:

Age is presented as a modern alternative to GPG that solves many of its limitations while maintaining security.
Age stands for "Actually Good Encryption" and has implementations in Go and Rust for improved security compared to GPG's C implementation.
Age uses smaller keys that are easier to store physically and has a simpler interface with no configuration options.
Files can be encrypted for multiple recipients simultaneously using Age.
Age supports encrypting for SSH public keys in addition to its own keys.
Age allows encrypting files for GitHub users by using their SSH keys from their profile.
Age offers a better user experience than GPG while maintaining an equally high level of security.

Why still org-journal?

I've considered using org-roam-dailies instead of org-journal. However, after some reflection, I'm not entirely sure why. Org Roam supports Age encryption, and org-journal has several PR fixes for various issues that have been neglected (this is not a judgment of the maintainer, but problems like journal files being decrypted whenever the calendar is invoked are troublesome). I think I was just seeking a quick solution to resume journaling.

Setup

Now that you've listened to me ramble on for a bit, here's the actual setup. This is using Doom Emacs.

packages.el

(package! age)

config.el

(use-package! age
  :init
  (setq! age-program "rage")
  :config
  (setq! age-default-identity "~/.ssh/id_ed25519"
         age-default-recipient "~/.ssh/id_ed25519.pub")
  (age-file-enable))

Went with rage, because Rust. Also there's pinentry support through rage.

config.el

(after! org
  (setq org-journal-encrypt-journal nil
        org-journal-file-format "%Y%m%d.org.age")

Only thing I had to do then was turn off the built-in gpg support on
org-journal, and update the naming scheme to have age as the suffix and it just
worked.™

Why I'm hyped about Julia for Bioinformatics

Edmund Miller — Wed, 01 Jun 2022 19:12:59 +0000

Julia might just change the game for bioinformatics. Bioinformatics is starting to heat up as a field, and I think we have a lot of unique issues starting from the days of perl and the Human Genome Project.

Based off a recent recommendation from my friend Teco

Two Language Problem

Plenty of people have written about this with Julia. Lots of scientific communities may use a high-level "scripting" language to manage their business-logic and then drop into a low-level language such as C/Fortran/Rust to highly optimize the bottleneck.

In bioinformatics, we have a 5 language problem. From the perl script written before the first generation of Next Generation Sequencing, to packages like DESeq2 that aren't going to leave anyone's toolbox anytime soon, but no one is going to rewrite, and instead are going to spend time teaching R to every incoming generation of bioinformaticians just so they can use these influential packages. That's not including python, Rust, and every bioinformatician's favorite, bash. That's not including if you want to contribute to any GATK CLI tools written in Java.

Now, workflow managers such as Snakemake and Nextflow have fixed the majority of those. Just stick those scripts in a container that acts as a time-capsule of versions long forgotten, and you can use them for just what you need and put them back in closet.

But what about new scripts? When you're starting a new bioinformatics project in 2022, do you follow in the footsteps of the pioneers that came before you, and learn how to call C functions in an R package? Or would you rather just see this beauty.

But what about my C functions that are highly optimized?

What about our in-house python library that interacts with all of our sample tracking and pulling files temporarily from s3? "I don't have time to figure out how to untangle that mess" you say. The Julia community wants to keep all of those import scientific scripts written. Packages such as RCall.jl, PyCall.jl, and plenty of others housed under Julia Interop allow for legacy code to fit right into new code. As scientists, we are constantly standing on the shoulders of giants, and Julia is enabling that.

BioJulia

Julia has a wonderful open-source structure. Since it was created, only a decade ago there's not a lot of legacy things to maintain and everything can be fresh and inclusive. Take for example the heavy use of organizations to house these code repositories, which prevents packages from going unmaintained and orphaned when the creator moves on.

While it's a relatively small community, they've covered a wide range of the various file types that we deal with on a daily basis. I hope to dog food most of the packages to fill in some missing pieces, and improve documentation and create some content for the community. The part that I found difficult was finding the people based on the website. I joined the Gitter to ask a question, but luckily someone saw the message and told me that most of the real-time chat happens in the #biology channel in the Julia slack.

Designed for Scientific Computing

It seems like bioinformaticians always want to do things in the most efficient path, but solving for a different variable than most. In a recent episode of screaming in the cloud, Lynn Langit mentioned that in finance, they care about getting the results as quickly as possible. The cost of the computing isn't a factor. In bioinformatics, they're trying to solve for both time and cost, trying to find the local minimum between both. There are plenty of time results don't need to be instant, and waiting a few days to stretch a grant out is a necessary evil.

Julia is fast, and that's been said numerous times, so you're probably guessing I'm going to say you can save money by decreasing your compute time. While that's true, the piece that I think people aren't solving for in that equation is developer time. Julia was designed from the ground up as a general programming language for scientists (Why We Created Julia).

We want a language that's open source, with a liberal license. We want the speed
of C with the dynamism of Ruby. We want a language that's homoiconic, with true
macros like Lisp, but with obvious, familiar mathematical notation like Matlab.
We want something as usable for general programming as Python, as easy for
statistics as R, as natural for string processing as Perl, as powerful for
linear algebra as Matlab, as good at gluing programs together as the shell.
Something that is dirt simple to learn, yet keeps the most serious hackers
happy. We want it interactive and we want it compiled.

That sounds like a bioinformatician's dream to me! Think of all the time we can save on developer experience, not trying to hack out some extra speed, or fixing broken dependencies (or a complete lack of specified dependencies!). Allowing legacy code to be treated like the crown jewel in our metaphorical software crown, and wrapping it in some gold Julia code like it deserves.

Call to action

I plan on working to increase the visibility into Julia, specifically for bioinformatics. I always love this Venn diagram to explain to people what bioinformatics is. I think it'll be natural to cover JuliaData, JuliaStats, and BioJulia to cover all three and show people how the three intersect.

How to get started with Julia

Attend JuliaCon 2022 (It's online and free to attend!)
Listen to the Talk Julia Podcast
Go through some courses on JuliaAcademy
Check out the work by Logan Kilpatrick, the Julia Dev Community Advocate