Hacker's Diary

A rough account of what I did with Emacs recently.

December 3
I'm inclined to take a crack at setting up emacs-lsp again, if only because some recent TypeScript work has had me occasionally reaching for Visual Studio Code to do some stuff and then spending the next ten minutes swearing because it doesn't have Emacs keybindings and I'm apparently hardwired to use Ctrl-a and Ctrl-e a lot, both of which are intrusive to current activities in VSC. This led to me reading through my entire .emacs (which, for historical reasons, is in fact .xemacs/init.el) for the first time in a long time and wondering just how much of it is still relevant - never mind feature support for Emacs 18.59, which hasn't even been compilable on modern systems for some years now, there's also support in there for things I no longer use, like the VM mailer, BBDB, and GNUS. Oh, and ange-ftp for that really early Internet feeling.

Keeping notes this time, too, and following the Vanilla Emacs instructions from the site since I'm on macOS and not using one of those fancy emacsen.

Step one, delete all traces of lsp I can identify and restart emacs: done.

Step two, package-install lsp-mode: done.

Step three, and this is where I have to think about it a bit, install a bunch of additional packages. Some of these resulted in poor use of limited screen real-estate; I suspect they're built by and for people who spend all their time not using laptop screens. I guess I can try 'em out and see what works and what doesn't. So, package-install lsp-ui, flycheck (already installed?), company-mode (same), lsp-treemacs, helm-lsp (missing dependency popup.el), lsp-ivy (package tarball not found), dap-mode: well, that was a partial success. M-x package-refresh, and now helm-lsp is missing a different dependency, but I managed to get lsp-ivy. Guess I'll do without helm-lsp, which in any case seems to overlap lsp-ivy?

Step four... ok. This is where I have to glue things together to make them work. The instructions suggest setting up for all programming languages by using prog-mode-hook so I guess I'll use that, plus defer loading and what not: (require 'lsp-mode) and (add-hook 'prog-mode-hook #'lsp-deferred)

Step five, restart Emacs: done.

Step six, open a TypeScript file, get prompted to install a language server, get prompted as to whether I want LSP to be active for this file, and off we go. Gritch gritch, it didn't bury the Comint buffer from the install.

Ok, so it's doing various syntax checks, but it's not importing the library definitions, which is partly why I wanted this (saves me trawling through pages of CDK documentation, for example). So I guess I need more configuration. Cunningly, there is lsp-doctor which tells me I need to mess with read-process-output-max, something that the install process neglected to mention. It looks like I'd also jacked up the value of gc-cons-threshold to something silly, so this time I'm paying attention to guidance to merely double it until performance improvements stop. Restart and try again.

There's a section in there on using plists vs. hash-tables, but it gives no indication what the tradeoffs are other than that plists are better - so why not enable that by default?

Step seven, did some tuning and it's still not helping me with my AWS CDK completion.

Ok, so this seems to be a fight between what the compile-chain is willing to work with and what the LSP is complaining about. So for example import { aws_ec2 } from 'aws-cdk-lib' compiles just fine, but LSP is insisting that aws_ec2 is not exported from aws-cdk-lib, and flipping it around to import * as aws_ec2 from 'aws-cdk-lib/aws-ec2' complains that aws-cdk-lib/aws-ec2/index.d.ts is not a module, neither of which seem to inhibit actual complilation / execution.

Checking the Languages page of the lsp-mode docs, I discover I chose the one TypeScript language server which was unmaintained. Of course. Is there a lsp-uninstall-server? No there is not. Kill all the buffers, quit Emacs, nuke the cache directory where it downloaded the server because it's the only thing in it, and start editing again.

Installing the recommended server: crashes on startup without showing me the error. (What step am I on now? Is this still part of one of the previous steps?). Digging around in the buffers I find "error: unknown option '--tsserver-path'". Trawling in the package cache turns this up in lsp-javascript.el and the changelog for the language server itself and appears to be a going concern? For good measure, the lsp log appears to be trying to pass /usr/local/bin/tsserver as the server path, which doesn't seem right in any case. Excellent.

Digging a bit more, as best I can tell the version of the NPM wrapper around the typescript server it's installed doesn't support the --tsserver-path. So I guess I'll see if I can prune that out.

This is getting tedious. Remove the cached files and try again. It's using npm to install the typescript-language-server and not getting the right version, as best I can tell, but there's no obvious indication why that might be.

Ah, I see my problem. I foolishly chose to install from the Stable MELPA repository rather than the, I guess, YOLO repo. Sigh. Revisiting step three to check package versions... right, well, that went great assuming I can ignore the various compiler warnings. Let's restart Emacs again, shall we?

Off to a flying start with Error running timer: (void-variable lsp-ada-project-file). Wonder if that's some sort of hangover from previous adventures in this space, given noone ever seems to provide a cleanup process?1 Apparently this is a reported bug and the fix is take off and nuke the site from orbit, it's the only way to be sure. Delightful. Exits Emacs for the tenth time, deletes entire directory of cached crud, starts over.

FINALLY. I actually had to do the exit-cleanup-restart process twice, because evidently I missed something, but now my TypeScript editing is working as intended. I'm going to hold off doing anything silly like customising it for the moment.

Ok, that's kinda funny. The one language definitely not supported by lsp-mode is ... Emacs Lisp. And you can just imagine the arguments being used by People Who Know Better Than You about why this is The Right Thing.

Tomorrow: figuring out which of the six Python LSPs is the best one for my use-case, given that last time I got lost in a maze of Microsoft "documentation" that didn't make sense to me even in the context of the editor for which it was written.

After we watched The Ninth Gate a couple of months back, I picked up a paperback copy of the source novel (The Dumas Club) and reread it. I'd forgotten details of the original story and quite how much was lost by the excision of the eponymous club from the movie.

1. Turns out there's a package-delete. I gave up after looking for package-remove and package-uninstall.

December 2
Also a new season of Doctor Who started last week. So that's a bit of fun.

December 1
Oh hey new season of Slow Horses. Let's be having you, then.

previous month | current month

Another year closing out.