Doom[0] (and Spacemacs probably too) supports lsp-mode quite well and it mostly works out of the box - for some languages more than others. As someone who only recently started using emacs it's been a great experience.
I've never had much luck with Doom or Spacemacs. It's probably at least 6 months since I gave them a drive but I vaguely recall them being pretty oriented around the subject-matter files being on the local filesystem, and in fairness that's a pretty reasonable assumption for a lot of users.
As much as I like full-color and other local-emacs niceties, I've long since knuckled under to the fact that usually my local appliance is unlikely to either complete my builds in a reasonable timeframe and/or have cuDNN properly configured.
Does either Doom or Spacemacs in fact run well under e.g. `tmux` on a heavy box somewhere? It might have been the case that I missed it last time I looked, it might be the case that one or both have since added that as a use case, or some other thing.
As other comments note, TRAMP is the way to go for remote work. I’m able to do everything on a remote / AWS / GCP box that I would do locally. If you’re into Deep Learning / data science you can also run Jupyter Notebooks in EIN with, say, a GCP Vertex / AI platform backend (though EIN isn’t 100% reliable for every production use case).
emacs is most certainly an acquired taste but, like most acquired tastes, is cherished by those who persist and come to love its flexibility, extensibility and power.
I’m one of those people.
No matter what else I try — and I still really enjoy using VSC as a backup — nothing else comes close to my particular set of workflows (mainly data science / deep learning / AI research across Python, C++, R, TeX). Throw in the power of org, beamer, pdf tools, journaling, email, rss, web browsing — you name it — all in one place…I really never need to leave it.
Oh that would be great. If you get writer‘s block or if you‘re looking for ideas on what to write about, feel free to DM me (Twitter handle in my profile).
I can tell you a whole bunch of questions I‘d have as someone who considers himself a pro user and who‘s been hearing about Vim and Emacs a lot, hears the „calling“ of greater productivity and ergonomics and an improved human-computer-interface, but has never quite been able to take the plunge.
Yes, Emacs can run very well under tmux on a powerful remote host. I do lots of development that way every day at work. It does take some configuration, and it really helps to have a modern terminal emulator (I use iTerm2 on macOS). Here are some unexpected things I have working with tty Emacs under tmux:
* 24-bit color themes[0]
* Hyper key bindings, also bindings like C-., C-;, etc
* Icon(all-the-icons) via alternate non-ascii "icons-in-terminal" font
* Mouse support w/ scroll wheel (xterm-mouse-mode)
* System clipboard integration (OSC-52)
* Very nice in-emacs terminal emulation via vterm
I build my own Emacs on these powerful remote hosts which I've automated with some Ansible scripting, because the OS vendor's Emacs packages are almost always a couple revisions behind. This way I can build in things like support for native compilation, modules (required for vterm) and rip out things I don't want or need like X support, jpeg, png, gif, etc.
As long as your latency via SSH to the remote host is reasonable, in my opinion this is approach is considerably better than what TRAMP offers in terms of speed and ease of use.
It's easy to forget this is an option because it's so rarely practical nowadays what with all the bitmap graphics and 3D acceleration requirements for even half-decent performance, but Emacs actually still works fairly well over a remoted XWindows connection. There's a bit of startup slowdown, and sometimes when switching back to it from another window it may take a moment to redraw, but most editing usage is surprisingly good. Of course this depends on latency to the target.
This may be as simple as "ssh -X $TARGET" and running "emacs". You'll know fairly quickly whether it's practical or not.
That's interesting, I haven't used `tramp` seriously in awhile (ditto `sshfs` etc.)
How do you find the experience of running the build remotely but getting error messages in a local buffer, or running `git-grep` when LSP pukes for whatever reason, or any of the other stuff that is fairly straightforward when emacs is on the same box as the source and build tools?
I don't ask out of snark: I'd friggin love to host emacs on my appliance and seamlessly interact with the real machine, and I gather VSCode has a pretty solid story on this, but I've failed to get that result enough times with emacs that I sort of timed out on it.
If you have e.g. dots on github or whatever that make this fly well I'd love to test-drive it.
You might be able to save me some research on this: can DAP drive GDB/LLDB in a seamless way without VSCode as a front-end? GDB has always felt like a time machine back to 1987 at best, `pwndbg` is like a big upgrade on GDB usability against that baseline.
Sidebar: `pwndbg` is extremely easy to build and install and makes terminal GDB suck mucho less, but would be no match for an LSP-style integration that didn't have a ton of rough edges.
The Python lsp backend (using pyright) is really nice. I used it when I was tracking every error I made when coding the Advent of Code recently. It was interesting to create "modern" Python using types and see what errors it would catch.
I've tried a few of the Python LSPs, but not `pyright`. Given the upfront cost of getting either `eglot` or `lsp-mode` to play nice with a new backend I'd really benefit from a TLDR on the cost/benefit. I tend to just say fuck it and use the Jedi backend even though it's far from precise.
What sets `pyright` apart? As it happens I'm reworking my dots at the moment and I'd like to capture the point-in-time SOTA while I'm at it.
It's very good, but I've found it to struggle somewhat on large and complex codebases. I have been meaning to try lsp-mode instead, but have yet to get around to it since tide-mode is mostly good enough; since they both use tsserver as a backend, I expect the user experience is probably much the same.
As an aside, I don't recommend following the article author in disabling Eldoc integration. Enabled, that will give you types for the thing at point in the message area, which is often quite useful and especially so with unfamiliar codebases.
interesting, i used to use gtags for browsing c but js required additional dependencies so i abandoned it. If you are using etags for js/ts can you point me to your tag syntax file? i checked here but couldn't find js/ts and i don't want to write it by myself ;-) https://www.gnu.org/software/emacs/manual/html_node/emacs/Ta...
YyyyyyyyyyyyyyyyyyuuuuuuuuuuP. 9 times out of 10 it takes me right where I want to go. It's lightweight and fast. And on that 10th time it gives a list of choices to jump to.
Indeed, the "etags" shipped with Emacs does not support JavaScript. Sorry. If you don't want to mess with its --regex argument, you can install "exuberant-etags" instead:
Yes. There are two major "flavors" I know of: 1. doom-emacs and 2. spacemacs I've only tried spacemacs and after a brief stint with it I was able to roll my own init.el by use-package'ing the things I liked and tinkering with it. glhf
Doom Emacs and Spacemacs are the most popular two. I recommend Doom Emacs although Spacemacs is what I started with and I find it to be more user friendly.
Like others have said, Doom is pretty good these days. It's a bit on-the-edge (the main installation comes from the master git branch) but seems to usually work.
If you're a Mac user, it can be a more comfortable form of Emacs: it goes to great lengths to act like a typical Mac application. Unfortunately it's also based on an older version of Emacs, so you miss out on some things.
I recall an interactive tutorial and practice tool that helped you learn emacs keybindings. It taught all of the previous/next character/word/expression/line key bindings. It helped develop muscle memory. It was web-based (I think), but I can't find it anywhere. Can anyone help?
No. That's not it. C-h t isn't really interactive. It's just a tutorial you can edit. The program I remember was a typing tutorial just for key binding.
Eglot is written by a regular Emacs contributor and maintainer, and as a result is much higher quality code. lsp-mode is written by volunteers on Github without a lot of Emacs Lisp experience (it shows), the code is pretty bad at places, definitely over-engineered and I wouldn't recommend it.
Even if the things you say about lsp-mode are true (which I don't think they are), lsp-mode has many features that eglot has no alternative to at all.
I also feel that lsp-mode's features are higher quality overall, with the downside of depending on packages and features not built into emacs itself. An example of such a feature is lsp-mode's project integration, it uses projectile which is much more powerful and useful than the built in project.el. Another example is using flycheck instead of flymake for on-the-fly diagnostics.
I would not say either package is better than the other because they are so different, and have such different philosophies. Eglot is much more minimal and tries to use native emacs features when possible, preferring minimalism over features. lsp-mode brings in a lot of features and prefers to use third party packages instead of built ins.
I used eglot for a little while before trying lsp-mode and decided that I personally prefer lsp-mode overall, with both being great options. I would recommend anyone curious to give both a try and decide for themselves.
lsp-mode maintainer here. I may assure you I know how the traditional elisp is written and I simply dont like it. Happily lisps allow you to write in different styles I can tell you that a lot of people find lsp-mode's source code more readable(in addition to being faster). To give an example of the differences in the mindset: Emacs core developers have `first`, `second` and `rest` deprecated in favor of `car`, `card`, and `cdr`. I will do the opposite.
Of course, there are problematic sections (so do eglot) but keep in mind that `lsp-mode` and emacs-lsp organization has ~10 times more code and contributors.
Hey, total aside: thank-you. Thank-you for helping to make Emacs competitive again. If not for lsp-mode I wouldn't still be using Emacs, even with 30y+ of enjoyment from it.
Staggering to imagine a developer using emacs would use some random community package corner-case function to install and keep updated an important package written in the same language he programs with.
These are the same developers who want a good out-of-the-box experience. It seems to me that lsp-ui is meant to replicate the features of VSCode, it's not surprising the same developers want to make it easy to install language servers.
I'd prefer to install pyright myself in my own node virtualenv rather than having it dropped into ~/.config/emacs/.cache/lsp/npm/pyright, but I understand why autoinstall is an attractive option.
What would they do when it inevitably breaks? Google won't bail them out on this one. What if there's a security issue with the server, are they going to have it up to date? Are they going to cry wolf online about how this ancient editor doesn't work for them? I understand some may want those poor souls locked into vscode to see the light, but this isn't the right way to do it. Emacs is great because it's rock-solid and incentivizes good practices, this is the complete opposite.
It uses the package manager of the system, or the one native to the language, to install servers. Ie, it uses nuget to install omnisharp. The same tools are used to update the servers.
Feature regressions and security holes from those sources will effect everyone, even those installing manually.
the installation isn't so much a thing as the "guarantee" that the installation happens in the place Emacs expects it to be, without having to futz around with PATH and the like.
It's not that it's hard, but it's Yet Another Thing That Can Go Wrong.
lol. I've been developing code with emacs for 25 years and I'm fine with this and would be annoyed if I needed to figure out how to install every language server for every language I use.
With all due respect to the core Emacs team (which is a substantial amount) being steeped in Emacs Lisp traditions is hardly an advantage. ELisp is a weaker language that has only managed to hold on because it is embedded in Emacs by default.
It is quite telling that Emacs is the only place that ELisp gets used as a style. Compare that to a lisp like Clojure where people love implementing Clojure in strange new places. Or Common Lisp which has more than 10 major implementations (and one in Emacs, naturally). Nobody chooses to use ELisp without serious prompting.
Someone writing bad ELisp doesn't say much about the quality of a package or how useful it will be.
I doubt it. Bad code takes longer to write, understand and is less maintainable. But it is rare that those are the issues that make or break an OSS project. Typically the maintainer's goals and motivation counts for much more.
And besides "good code" in ELisp is a bit of a funny one. Lexical scoping is a relative innovation.
> being steeped in Emacs Lisp traditions is hardly an advantage.
I used to think this, but sometimes this determines how deeply your package integrates into emacs.
The obvious example here being seamless tramp support.
IIRC this is demonstrated in this very interesting blog post[0] about debugging why opening a remote file is slow in the projectile package, likely didn't exist in the project.el alternative that is more steeped in those traditions.
As a user I shouldn't have to care/don't care about the code quality as long as it works. If lsp-mode provides more/better features there are very few reasons to not use it.
Maybe (actually, very likely) I'm just an idiot, but I never could get lsp-mode to work with Tramp. With eglot, add the path and off to the races. That alone keeps me on eglot.
Only for code development, unless I suppose there's an lsp-mode for TeX, for autocorrection when sending mail or writing random documents, etc. Which I suppose is only a matter of time.
> for autocorrection when sending mail or writing random documents
Complete-at-point is integrated with company-mode, of which I use lsp as a backend to serve suggestions. So ... In a way, yes, I do get spelling suggestions through the same mechanism that lsp works.
Even if there is an LSP server for (La)TeX, will it ever be better than AucTeX already is?
I think for a languages like Python, LSP servers are interesting but for some other languages the existing tools are already very powerful: OCaml with merlin comes to mind for example.
That said, the LSP approach is nice and makes many editors able to profit from each language server :).
UX depends heavily on the quality of the packages in your init.el; if a maintainer has gigabit fiber at home and writes their elisp to hit the network during `(interactive)` elisp, it's going to feel slow for people on worse connections.
emacs/elisp aren't all that opinionated, there's lots of rope to shoot yourself in the foot with
Got it, thanks for clarifying. It was not a criticism, merely curiosity. :) I used to use Emacs back in the late 90es; since then I have mainly used vi in various permutations.
Apologies if my post came off as harshe. I see this critique a lot, but it doesn't make sense to me. Especially since compilation mode has existed forever.
I do grant that some things could use extra support for async, so it will be a welcome addition. But there is already a lot of capability today.
I don't know: I'm running a "native compilation" branch of Emacs and everything is really fast. I'm not saying once in a rare while something chokes a bit but I made sure to eliminate some of the usual suspects in my init files (for example not launching lots of minor modes on gigantic files or on files with very long lines).
In my experience Emacs, over the years, kept getting faster and faster. The "bloat", if any, is progressing way slower than CPU ares and certainly way slower than the bloat in other IDEs.
The problem isn't some 'bloat' in Emacs, but that running some processes started from Emacs almost grinds Emacs to a halt. Which always has been like that, but nowadays I start way more programs in the background.
About getting faster: 27 has been the first Emacs that was usable with LSP. I've been using Emacs more than 25 years now, and can't say that it is as fast as I remember it 10 or 15 years ago (on much slower hardware), but it does have _way_ more features now.
Speaking of gorgeous themes I’m going to boost Mr. Rougier’s excellent work: https://github.com/rougier/nano-emacs. The rest of his portfolio is also well worth a look.
I disagree, Emacs customization is a means to an end, to get your personal perfect editor so you can better do the objective: editing texts. Customizing Emacs is not fun (for most of us), is not building Lego, it is a chore we have to go tru to get to the good part that is having a perfectly tuned editor to work with. Having a sane default out-of-the-box-experience wouldn't detract from the Emacs experience, and it is something that is missed.
But then, I'm suspect to talk, I left Emacs almost two decades ago and never looked back, and among other reasons, it was exactly because it was so crappy "out-of-the-box", so every new computer I had to use meant always having to deal with that.
[0] https://github.com/hlissner/doom-emacs