Hacker News Reader

Comment by tikhonj | Hacker News Reader

I'm not sure about the specifics, but providing something a lot more "batteries-included" seems to be the idea behind Emacs distributions like Spacemacs and Doom Emacs.

One difficulty is that language-specific tools (language servers, linters... etc) are standalone pieces of software with their own dependencies, requirements... etc. It's hard to bundle together a fully "batteries-included" Emacs without figuring out a way to manage native software and services.

I think this is one place where Nix can be a real advantage: even if you don't care about Nix's reproducibility, it's ability to manage Emacs, Emacs packages and language-specific tools is pretty unparalleled. If I had some more time on my hands, I would try putting together a Nix-based Emacs "distribution" with some easy way to configure which languages you want to work with. Coupled with lsp-mode and language-servers, this has some real potential!

View on HN

I'm positive some sadist somewhere in this world has all the software on their OS as a nix expression. I'm also positive that at least one of these people has a fully featured emacs IDE and all the required dependencies as part of that expression.

Totally down to try it if anyone has it.

One thing good about just standalone vim though is how portable it is. I can ssh into any server and fire it up. I also want this for a IDE. I want a console level IDE to fire up on any server I ssh into and if it's not in that server I want to be able to use any package manager to DL it easily.

I can't see any editor/IDE solve the above problem unless the editor becomes the ssh client itself. With that setup in place then my IDE can go anywhere.

funnily enough it's something I've been working on for my personal dotfile setup but instead unfortunately decided to go with ansible for now despite being a big fan of both nix and nixos. Nix was just a bit too heavy for some of the small lxc containers etc I wanted to setup.

"the editor becomes the ssh client itself" is effectively how I use Emacs. TRAMP (https://www.emacswiki.org/emacs/TrampMode) makes editing remote files pretty much as seamless as editing local ones. I even semi frequently do slightly-crazy-seeming things like open files via chains of several ssh hops and I can "save" them (read: marshal a complex operation involving scp, base64, and other sourcery) in exactly the same way I can save something to the home directory on my workstation. TRAMP is a default part of the Emacs distribution (and has been for over 10 years), so it doesn't require installing extra packages or even enabling anything. It's just on by default.

This capability, plus "frame" management commands and the various terminal modes make my use of Emacs roughly equivalent to they way I see colleagues (I'm an ops/sysadmin type, not really a developer) using vim + tmux.

Oh yeah, I am one of those people myself[1] :). But my setup is quirky and hard to customize. (Well, hard to customize for other people, anyway.)

Nix had a learning curve, but once I got over the initial hump, I stopped wanting to manage software any other way.

To get from my setup to what I'm thinking of here, I'd need to organize it as a package that's convenient for others to depend on, fill in a bunch of missing systems and factor out support for specific languages and tools into some kind of module-style config system. Thinking about it now, it's probably just a few days' worth of work.

Emacs, by the way, does work as an SSH client (via TRAMP). I do all my work on remote servers by SSHing from a local Emacs. It's not perfect, but it works well enough in practice that I haven't tried finding anything better.

[1]: https://github.com/tikhonjelvis/dotfiles

you could consider sshfs

This actually exists for Common Lisp: https://common-lisp.net/project/lispbox/

It would probably be doable for other languages, if you were so inclined

Emacs mostly has problems with external language servers because its plugin model is archaic and brittle to a large extent compared to that of say VS Code. It's also far more flexible but with power comes responsibility, and I've found Emacs extensions far more likely to interfere with each other than in less composable editors. You don't need Nix to fix this problem.

Given the brittleness there should be at least a single configuration that works. I believe that tikhonj is right in the sense that nix can capture this configuration. Nix is not required but I can see how it can help.

Nix would be useful for a description of the non-Emacs dependencies. Particular versions of the compiler and LSP program. -- Some languages are more fickle about this than others.

Nix would help pull in the right versions of all the external non-Emacs packages you would need for a real IDE experience. Almost all the issues I've had with Emacs plugins have boiled down to poor interactions between Emacs and external software (wrong versions, wrong paths... etc), and Nix could fix basically all of it.

As a bonus, using Nix to manage Emacs dependencies would also give me full control over exactly which version of each package to pull in. This would create much more of a "distro" experience without needing any extra infrastructure.

This was indeed the promise of spacemacs. I tried it a few times and roughly 30% of the advertised features were broken out of the box.

I've used Spacemacs for Clojure development for many years without issue though it looks like it isn't being maintained much now.

Reply on news.ycombinator.com