Running staticcheck with eglot and gopls

Another neat finding in Go’s language server. Basically, I wanted to include some sort of way to run some static analyser with my language server. I remember golanci-lint was long the “de facto” tool for this, but seems that staticcheck has grown a lot in popularity. So I wanted to integrate that with my gopls.

Naturally, the first step was installing the tool itself. Fortunately, that can be done super easily with just:

$ go install

Next I needed to enable this somehow with gopls. Again fortunately, all the possible settings for gopls can be found here. Including the simple variable for staticcheck. To pass in this setting to eglot, I need to configure variable eglot-workspace-configuration, which basically allows you to configure LSP servers specifically for a given project and given LSP.

To pass in the setting to the gopls, we need to pass in a plist with the configurations we want:

(use-package eglot
  (eglot-workspace-configuration '((:gopls . ((staticcheck . t))))))

;; OR

(setq-default eglot-workspace-configuration '((:gopls . ((staticcheck . t)))))

Naturally, you can pass any setting you desire that is available for the language server this way.

Generics-aware gopls in Emacs

I needed to write some funky Go code using relatively new Go generics in it, just to quickly notice that my LSP client in Emacs didn’t recognise those like you would expect. Fixing gopls was relatively straight-forward, since my issue seemed to be just an old version. So I just installed gopls while having Go 1.18+ installed. In my case, I had already generics-aware Go version installed but seemed like that I had installed my gopls version before the generics update, so I had to just reinstall it with:

$ go install

After that gopls was pleased, or at least my eglot didn’t complain about syntactical errors in my code. Pretty much immediately I realised that now my goimports was broken, so it didn’t organise my imports accordingly. I knew that gopls was able to do this stuff instead of using goimports, but I just never was eager to fix something that was already working. But since now it was broken, I decided to find a way to fix it.

What I did was just uninstall goimports from my machine and started relying on gopls for organising my imports. Previously, I had set my Emacs so that when I saved my files, it always ran goimports (when working on Go files, of course). Setting my eglot to do that was relatively simple, but then I noticed that it only formats my code, it doesn’t automatically import the libraries like how goimports does.

Like I mentioned earlier, gopls should be able to work exactly like goimports in this case, so I had to start digging on how I can make my eglot to do this. Basically, how gopls does this, is it uses source.organizeImports action for it. So I needed to run that somehow on save.

Fortunately, eglot exports all these code actions that the LSP can do with a neat function called eglot-code-actions. After some tinkering, I was able to call that before the save:

(use-package go-mode
  :ensure t
  (defun tok/gofmt-before-save ()
    ;; Run `eglot-code-actions' only in buffers where `eglot' is active.
    (when (functionp 'eglot-code-actions)
      (eglot-code-actions nil nil "source.organizeImports" t))
  :hook (go-mode . (lambda ()
                     ;; Using depth -10 will put this before eglot's
                     ;; willSave notification so that the notification
                     ;; reports the actual contents that will be
                     ;; saved.
                     (add-hook 'before-save-hook 'tok/gofmt-before-save -10 t))))

I decided to use gofmt-before-save, which comes from go-mode here since I noticed that if you would just run eglot-format-buffer formatting doesn’t open a new buffer where it lists all the errors and instead prints them in the LSPs messages. You can probably dig them somehow from there and print in a new buffer, but I liked already the existing behaviour of running gofmt with go-mode so I decided to use that one.

Small fix, but a really good one. Happy generics-aware hacking.

Finally Got My Emacs Setup Just How I Like It

So in recent days, I have stumbled upon some REALLY NICE (at least in my own standards) Emacs tweaks, which I wanted to share with you.

First, something very trivial, I knew that Emacs had some sort of jump to previous location etc., type of feature available, but I never got into using it. Turns out there’s is a built-in keybinding for that or a couple. First, one was C-x C-x, which jumps to the last position and selects the text from your current position. So, e.g. you jump to the beginning of a file and press that combination, it selects the text from the beginning to the last position. Which was cool for me, but I rarely need something like that.

That was enough for me for some time, but I wanted to tweak it slightly. I didn’t care about selection and wanted to centre the screen after the jump. Thankfully, this is relatively trivial to implement in Emacs with a single function:

(defun jump-to-mark-and-center (arg)
  (interactive "*p")
  (goto-char (mark))

(global-set-key (kbd "C-x C-x") 'jump-to-mark-and-center)

So I bound the old keybinding to that new function, which does exactly what I want. Lovely!

To the second lovely new configuration! I had longed for a feature in Emacs, where I could find a file based on the format of FILENAME:LINENUMBER. So, if I would have a file, let’s say and I would immediately jump to the line number 14 in that file, I would want to open that file with like most of the Unix tools print these file locations, but I just couldn’t do it in Emacs.

Thankfully, after some searching throughout the interwebs, I found some nice defadvice that fixes this for me:

(defadvice find-file (around find-file-line-number
                             (filename &optional wildcards)
    (let* ((matched (string-match "^\\(.*\\):\\([0-9]+\\):?$" filename))
           (line-number (and matched
                             (match-string 2 filename)
                             (string-to-number (match-string 2 filename))))
           (filename (if matched (match-string 1 filename) filename)))
      (when line-number
        ;; goto-line is for interactive use
        (goto-char (point-min))
        (forward-line (1- line-number))))))

And BAM! It works just like that!

And the last lovely new feature! I use mainly vterm inside my Emacs for my terminal needs. I always wanted to use it so that when I’m inside a certain directory in the terminal, I could just open some file in that directory, but unfortunately, by default, vterm only knows the directory where it was opened at.

Thankfully, after reading some documentation about vterm, it turns out you’re able to send certain character codes to emacs from your vterm session. So you’re able to make it so that when you open vterm in directory x and proceed to change the directory inside the vterm with many different cd commands etc. to something like x/many/different/subdirs, when I run something like C-x C-f in that vterm buffer, the minibuffer inside Emacs, would know that I want to file directory in the directory where vterm currently is, instead of the directory where it was initially opened.

This can be done by doing some shell tweaking. I use zsh myself, if you use something else, refer to vterm README.

# Enable the shell to send information to vterm via properly escaped
# sequences.
vterm_printf() {
  printf "\e]%s\e\\" "$1"

vterm_prompt_end() {
  vterm_printf "51;A$(whoami)@$(hostname):$(pwd)"

# Let vterm know what dir I'm in

If you happen to use screen or tmux, you might need to do some other tweaks in there, but these are mentioned in the vterm README.

In any case, when you define those to your .zshrc, vterm sends the information of the current directory straight to Emacs, so it knows where you’re currently at. Which is great!

To make that even better, I often noticed that I wanted to open files straight from the command line instead of running some Emacs command to open the files. Fortunately, vterm covers this also:

vterm_cmd() {
  local vterm_elisp
  while [ $# -gt 0 ]; do
    vterm_elisp="$vterm_elisp""$(printf '"%s" ' "$(printf "%s" "$1" | sed -e 's|\\|\\\\|g' -e 's|"|\\"|g')")"
  vterm_printf "51;E$vterm_elisp"

find_file() {
  vterm_cmd find-file "$(realpath "${@:-.}")"

alias e="find_file"

With these functions inside your .zshrc, I can run find_file inside vterm, and it opens the file in your current Emacs session. I just use short alias to run e somefile inside the terminal; it opens a new buffer for the file.

I have used Emacs for a long time, but these recent additions made it so much nicer. Hopefully, these are helpful for you too.

Adding Lunar Phases to Emacs' Org Agenda

As some of you may know, I’ve been a practising Buddhist for some time, focusing mainly on the teachings of Early Buddhism and Theravada. One aspect of this practice is keeping up with Uposatha, which is also present in other schools of Buddhism. Wikipedia describes Uposatha as follows:

The Uposatha (Sanskrit: Upavasatha) is a Buddhist day of observance, in existence from the Buddha’s time (600 BCE), and still being kept today by Buddhist practitioners. The Buddha taught that the Uposatha day is for “the cleansing of the defiled mind,” resulting in inner calm and joy. On this day, both lay and ordained members of the sangha intensify their practice, deepen their knowledge and express communal commitment through millennia-old acts of lay-monastic reciprocity. On these days, the lay followers make a conscious effort to keep the Five Precepts or (as the tradition suggests) the ten precepts. It is a day for practicing the Buddha’s teachings and meditation.

Uposatha days change from lunar month to lunar month, so there are no set days for those. But generally speaking, Uposatha is observed about once a week in accordance to the lunar phases. Which lunar phases are observed depends on the culture, but there are four phases to this: the new moon, the full moon and two quarter moons between those. Theravada cultures generally observe all four, but for example, in Sri Lanka, they tend to only observe the new and the full moon.

How these Uposatha days are calculated is quite interesting, and there is a paper published on GitHub by Gambhiro Bhikkhu about that.

Personally, I have followed these moon days by adding those to my Apple Calendar via the iCal link provided in the repository above, and I’ve been quite happy with that. Lately, though, I noticed that I tend to easily miss these days since I don’t often have notifications on or my calendar open when these days happen, which made me easily miss those. That got me thinking that it would be pretty cool to have those lunar phases on my emacs since that is most likely always open for me and I’m already mainly doing my time management in org-mode.

So I started digging around on how these could be easily added to my org-agenda, and then I found a built-in command from emacs that is at least the first step there called M-x lunar-phases, which basically prints lunar phases of the last, current and next month. So I started hacking around to try to get these to my Agenda view.

Not long after starting my hacking in this, I found a nice doc piece about some ad-hoc tweaks to be made to the agenda from org-mode, which actually made exactly what I wanted. What it involves is that I need to build an agenda file with these lunar phases so that the Agenda view in emacs picks those up.

So first, I needed to add some arbitrary file to my org-agenda-files. With use-package:

(use-package org
  (org-agenda-files '(<your other agenda files> "~/Documents/org/")))

Or normally:

(setq org-agenda-files '(<your other agenda files> "~/Documents/org/"))

I happen to have all my agenda files in my Documents folder on my macOS, so they just get synced across my devices, but naturally, you can use any path you want.

The file itself is pretty simple. Basically, we add a header to it with a single diary sexp calling a function, org-lunar-phases, which we soon define:

* Lunar phase

The org-lunar-phases itself either isn’t too complicated. It involves that we pass in the current day to it, which gets passed in in a relatively odd way via the diary sexp we used above, and after that we just parse the lunar-phase-list with the current day, or month and year in this case, since lunar-phase-list returns a list of lunar phases for the next three months.

(require 'cl-lib)

;; Pass current day to `org-lunar-phases', which is annoyingly in a stupid
:: format, (MM DD YYYY).
(with-no-warnings (defvar date))
(defun org-lunar-phases ()
  "Show lunar phase in Agenda buffer."
  (require 'lunar)
  (let* ((phase-list (lunar-phase-list (nth 0 date) (nth 2 date)))
         (phase (cl-find-if (lambda (phase) (equal (car phase) date))
         (lunar-phase-names '("● New Moon"
                              "☽ First Quarter Moon"
                              "○ Full Moon"
                              "☾ Last Quarter Moon")))
    (when phase
      ;; Return the phase to the agenda file.
      (setq ret (concat (lunar-phase-name (nth 2 phase)))))))

Naturally, you can get all fancy with those lunar-phase-names. Maybe adding emojis and whatnot if you’re into it. But in all simplicity, that is how you can add lunar phases to your agenda, and it shows as following in there:

10 days-agenda (W08-W09):
Monday     20 February 2023 W08
  Lunar:      ● New Moon
Tuesday    21 February 2023
Wednesday  22 February 2023
Thursday   23 February 2023
Friday     24 February 2023
Saturday   25 February 2023
Sunday     26 February 2023
Monday     27 February 2023 W09
  Lunar:      ☽ First Quarter Moon
Tuesday    28 February 2023
Wednesday   1 March 2023

One thing that I noticed from this was the fact the GitHub link above that I mentioned. That happens to produce a little bit different results for these phases. Every once in a while, some phases differ just a tiny bit. There is a mention that the calculation method used in that paper was related to how these days are calculated in Mahānikāya in Thailand, so there might be some variance compared to the M-x lunar-phases. But personally, I feel it’s close enough and quite beneficial to me.