Building an Intelligent Emacs(ianyepan.github.io)
ianyepan.github.io
Building an Intelligent Emacs
https://ianyepan.github.io/posts/emacs-ide/
99 comments
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 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.
Persist with it. It’s worth the payoff.
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.
Sounds great. If you were my neighbor I’d like to look over your shoulder some time.
Any pointers to blogs posts or books or videos that give a walkthrough of a system like yours, to get some inspiration?
Any pointers to blogs posts or books or videos that give a walkthrough of a system like yours, to get some inspiration?
A bit older http://emacsrocks.com One of my favourite episodes being http://emacsrocks.com/e13.html the ending is just awesome.
System Crafters yt channel is much newer and also amazing https://youtube.com/c/SystemCrafters
System Crafters yt channel is much newer and also amazing https://youtube.com/c/SystemCrafters
Oh, great. Thank you!
I tell you what -- you've inspired me to start a blog and write about this! Will post here when I get it up and rolling.
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.
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.
I find tramp to be super slow when doing things like magit or rgrep. Slow enough that I just wind up having enacts on the remote boxes.
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.
[0]: https://muppetlabs.com/~mikeh/ttyemacs.png
* 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.
[0]: https://muppetlabs.com/~mikeh/ttyemacs.png
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.
This may be as simple as "ssh -X $TARGET" and running "emacs". You'll know fairly quickly whether it's practical or not.
I usually use tramp or something with my local emacs to control a remote box. Multiple remote boxes, actually.
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.
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.
I remember this all working well many years ago so long as:
- 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...
- 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...
I haven't tried it out, as I've long been more of a logging-driven debugger, but there's an analogous tool for debuggers called dap-mode:
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:
https://microsoft.github.io/debug-adapter-protocol/
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:
https://microsoft.github.io/debug-adapter-protocol/
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.
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.
If you're asking because you want to use LLDB or GDB inside Emacs, the RealGUD project is a good option: https://github.com/realgud/realgud
I'm not sure.
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.
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.
Ah thank you for this, I ran across pwndbg some months back and I've been trying to find it again since.
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.
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.
> What sets `pyright` apart?
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
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
Thank you!
The org mode, a single mode for todo, notes and mindmaps is enough reason to learn Emacs
off topic: I've found tide-mode[0] to be pretty good to use with typescript on Emacs
[0] https://github.com/ananthakumaran/tide
[0] https://github.com/ananthakumaran/tide
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.
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.
i have stopped using lsp with javascript as js lsp servers are memory/cpu hogs. I wish there was tag based system for js/ts
Well, with Emacs you can als just use „etags“ to create an index into your JS code base out of the box. And then use „M-.“ to jump to definitions.
It’s very fast and usually brings you right to a definition — unless your method/function is called very unspecifically.
It’s very fast and usually brings you right to a definition — unless your method/function is called very unspecifically.
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...
While I have no idea about tags, I want to say that you may find something as simple as dumb-jump[1] does what you want most of the time.
[1] https://github.com/jacktasia/dumb-jump
[1] https://github.com/jacktasia/dumb-jump
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:
sudo apt install exuberant-ctags
ctags-exuberant --list-languages
sudo apt install exuberant-ctags
ctags-exuberant --list-languages
For those coming from say VS Code is there an opinionated “flavor” of Emacs that comes pre-configured with batteries and everything included.
A place to test drive it’s power and use of as a daily driver before being confident to properly “roll your own”.
Curious.
A place to test drive it’s power and use of as a daily driver before being confident to properly “roll your own”.
Curious.
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
1 https://github.com/hlissner/doom-emacs 2 https://github.com/syl20bnr/spacemacs
1 https://github.com/hlissner/doom-emacs 2 https://github.com/syl20bnr/spacemacs
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.
Besides Doom and Spacemacs that others have mentioned, there's also Prelude: https://prelude.emacsredux.com/en/latest/
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.
On the Mac, I recommend Aquamacs. It has many of the most popular packages pre-installed.
I use Doom Emacs, it's great.
+1 for eglot. it just works. vibes well with core emacs (and therefore minimizes bloat, among other advantages)
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?
You can access it in Emacs itself with C-h t
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.
It might have been https://keycombiner.com/emacs/
TLDR: lsp-mode is the future of emacs.
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.
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.
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.
And like Emacs core, eglot is missing important usability features. lsp-mode may not be pretty, but it fulfills the needs of its user-developers.
Ie, last that I looked, eglot had no equivalent to lsp-install-server.
Ie, last that I looked, eglot had no equivalent to lsp-install-server.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
0: https://www.murilopereira.com/how-to-open-a-file-in-emacs/
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/
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.
Edit: typo lsp
Edit: typo lsp
> unless I suppose there's an lip-mode for TeX
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.
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.
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 :).
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 :).
Or Common Lisp with SLIME or Sly.
https://github.com/latex-lsp/texlab
No clue how good it is, but it does exist and it's not the only one.
No clue how good it is, but it does exist and it's not the only one.
I just got started on Go and I am quite satisfied with eglot for now.
[deleted]
Don't want to be without it anymore.
Reminds me of the time I posted this https://news.ycombinator.com/item?id=29578748
Speech input with something like Vosk is a great idea too.
I struggled to understand LSP in Emacs vs Vim and wanted something short and concise to help me understand. This article did that. Thanks author!
What’s the experience like? From memory Emacs is single threaded so curious how it performs with external IO async.
I've never understood this criticism. Elisp is single threaded. Emacs has long had async capabilities with process buffers and sentinel functions.
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
emacs/elisp aren't all that opinionated, there's lots of rope to shoot yourself in the foot with
My concern is that this will remain the case, even when Elisp goes multi threaded. Such that most concerns won't really change, at all.
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 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.
It _is_ sluggish sometimes. It feels way less responsive than VS Code.
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.
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.
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.
My guess is this is mainly from the native json support. If you are using lsp, fast json will be a necessity.
But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?
But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?
It’s like any other modern editor except it’s more easily extensible.
Offtopic, but... that theme is gorgeous! Does anybody know its name?
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.
That seems to be moonlight theme on doom emacs
that looks pretty
I'm pro-lsp, but comparing Emacs unfavorably to other tools "out-of-the-box" is like complaining that your LEGO set doesn't come pre-assembled.
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.
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.
I left a decade ago and came back using doom and have gained a new respect for both emacs and lisp.
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.
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.
How many other programs that you stopped using two decades ago are still going strong with thriving communities?
I think they're going in the direction of having things enabled by default. It just takes time.
The default experience of Emacs these days is far from the experience 20 years ago.
The default experience of Emacs these days is far from the experience 20 years ago.
[deleted](1)
[0] https://github.com/hlissner/doom-emacs