waider dot i e

December 03: 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?¹ 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 02: Also a new season of Doctor Who started last week. So that's a bit of fun.
December 01: Oh hey new season of Slow Horses. Let's be having you, then.
November 29: It's easy to unsubscribe from this list! Just open the raw source of the email, find the List-Unsubscribe header, feed it to Python's email.header.decode_header, click on the URL this exposes, copy the page text into a translation app so you can figure out which thing on it is the "YES UNSUBSCRIBE" link, click on it, realise it's brought you back to the same page, hope it worked. Simples!

Not a huge amount of work, but I've sufficiently reverse-engineered the YNAB file format to allow me to add ad-hoc updates from a CLI tool. Been meaning to do this for a very long time, mostly since the company stopped developing their app and focused on a hosted solution.

First attempt to bring a backup up: ran out of disk. Dammit.
November 28: Trying to migrate my OpenHAB installation to another machine, which is apparently possible using backup/restore... which presumes the backup process works, of course. Some user assembly required, it appears.
November 26: Funny. Some website sending me a marketing email - which, you know, it didn't give me the option to opt out of - and the unsubscribe link goes through a click-tracker which is blocked by both my browser's adblocking software and the network-level adblocking built into the eero gateway. I did try to unwrap the URL to find out what it was targeting, but it's a binary blob which has been base64-encoded, then url-encoded, then any percent signs replaced with dashes, then urlencoded a second time; I was able to unwrap as far as the binary blob but after that I didn't feel like trying to pick it apart further so I guess I'll unsubscribe via an unfiltered device.

Digging through hardware... it seems my old 2007 MacBook has had some piece of hardware flake out, as it no longer runs on a healthy, fully-charged battery. Instead, it shuts down immediately. I understand from a little research that this is likely due to some fried circuitry and at this point it's not really worth recovering, so I'll likely just nuke the hard drive and drop it off somewhere for recycling. At least, I'll eventually drop it off for recycling. Going by my usual rate of progress on this sort of thing it's likely going to be gathering dust in a drawer somewhere for a few years yet.

More hardware: three Raspberry Pis, one of which I intend to take over home automation duties for various reasons. One of the three isn't booting headless right now, so that'll need investigation. Of the other two, a bunch of somehow-can't-be-hands-off upgrades need applying.

And more hardware: the aforementioned home automation has had two of the TRVs decide to fall off the network again. Last time this happened I tagged a TRV as failed, then re-added it as new to the network. I wonder if I kept notes? (checks ... apparently not.)

Aha. The unbootable Pi was on account of the fact that the PSU wasn't up to the job of the connected camera plus IR spots. Removing all of that allowed it to start up. It and its sibling are getting the next version of Debian installed ("bookworm") which, at the rate it's going, should be done some time this year.
November 25: Watched An Inspector Calls again. Really excellent piece and while I'm still not terribly keen on how they handle the ending it's definitely better on a rewatch.

I note once again that my ZWave network is being glitchy. Grr.

Git, however, seems to have straighened itself out, so at least there's that.
November 23: git has been behaving oddly for me lately. I have a repo on one machine, and I've been pushing things into it for literal years from another, and in the last week or two every change I make seems to randomly change the status of some other file locally. So I commit tvlistings/common.py and tvlistings/__init__.py shows up in git status as "added". My minimal set of git health checks both locally and on the remote all look ok. This is annoying and, obviously, slightly worrying. It smells awfully like some sort of integer overflow.
November 17: For a movie I'd seen no press or promos about, The Courier is an astoundingly good piece of work. Really well made, and not a sprawling epic - indeed it feels longer than it is, particuarly the third act, as I wasn't sure how it'd work out.
November 12: AWS has been nagging me for a bit to upgrade my RDS CA cert. I've been putting it off because it's not a push-button operation: it requires some thinking. This morning I figured I'd just go ahead and upgrade it and see what breaks; it's not like it's mission-critical.

Round two with the shredder was much more productive: I took some time to figure out how to tweak the cutting part of it so it would actually cut, and then it did a much better job. Gave me some actual mulch/compost material.