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.