Building an Intelligent Emacs
ianyepan.github.io
ianyepan.github.io
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.
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.
- the remote box has git, the LSP-server, or w/e you are trying to run - you use SSH control master: https://xenodium.com/speeding-up-emacs-tramp-via-controlmast...
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.
Persist with it. It’s worth the payoff.
Any pointers to blogs posts or books or videos that give a walkthrough of a system like yours, to get some inspiration?
System Crafters yt channel is much newer and also amazing https://youtube.com/c/SystemCrafters
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.
* 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.
This may be as simple as "ssh -X $TARGET" and running "emacs". You'll know fairly quickly whether it's practical or not.
https://emacs-lsp.github.io/dap-mode/
Like lsp-mode, it is also built on top of an open standard from Microsoft, the Debug Adapter Protocol:
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.
I can see that this extension claims to make debugging with GDB work in VS Code:
https://github.com/WebFreak001/code-debug
and that at least for emacs there exists a plugin to use that extension:
https://github.com/emacs-lsp/dap-mode/blob/master/dap-gdb-ll...
Not having tried it, I can't speak to how well it works, and I don't know if there are adapters for other editors.
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 works with Emacs (but I didn't try the fork of Palantir). I didn't have much problems setting up LSP clients with lsp-mode, didn't take much time.
My .emacs: https://github.com/Release-Candidate/Emacs
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.
It’s very fast and usually brings you right to a definition — unless your method/function is called very unspecifically.
sudo apt install exuberant-ctags
ctags-exuberant --list-languages
A place to test drive it’s power and use of as a daily driver before being confident to properly “roll your own”.
Curious.
1 https://github.com/hlissner/doom-emacs 2 https://github.com/syl20bnr/spacemacs
Edit: typo lsp
No clue how good it is, but it does exist and it's not the only one.
https://emacs-lsp.github.io/lsp-mode/page/lsp-latex/
> 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.
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 :).
Ie, last that I looked, eglot had no equivalent to lsp-install-server.
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.
Feature regressions and security holes from those sources will effect everyone, even those installing manually.
It's not that it's hard, but it's Yet Another Thing That Can Go Wrong.
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.
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.
If they're writing it on Emacs, then it is.
I mean, if you have an app running on the JVM, and the developers are poor at Java, you kind of would expect issues.
And besides "good code" in ELisp is a bit of a funny one. Lexical scoping is a relative innovation.
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.
0: https://www.murilopereira.com/how-to-open-a-file-in-emacs/
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.
emacs/elisp aren't all that opinionated, there's lots of rope to shoot yourself in the foot with
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.
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.
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.
But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?
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.
Having such a configurable tool is an invitation to the subtle with an attention to detail.
Free Software is so far away from the mainstream consumer culture and it provides an immeasurable value to those who invest.
The default experience of Emacs these days is far from the experience 20 years ago.