Threads for NeroLXIV
-
Its package ecosystem is in excellent condition and packages such as org-mode and eglot / lsp-mode make even the most demanding programming languages a joy to work with in Emacs.
I work on a large C/C++ codebase as part of my day job and use lsp-mode/eglot (currently eglot) to navigate the code, with very few extensions. I also use the latest mainline Emacs with native compilation. I have been using Emacs for over 25 years and my customization is best categorized as “very light”. In short, my Emacs set up is not much beyond what ships with it.
And it’s still just… slow. GCC has some pretty big files and opening them can take up to 10 seconds thanks to font-lock mode. (Yes, I know I can configure it to be less decorative, but I find that decoration useful.) It’s much worse when you open a file that is the output from preprocessor expansion (easily 20000+ lines in many cases).
Log files that are hundreds of megabytes are pretty much a guaranteed way to bring Emacs to a crawl. Incremental search in such a buffer is just painful, even if you
M-x find-file-literally.I had to turn off nearly everything in lsp-mode/eglot because it does nothing but delay my input. I can start typing and it will be 3-4 characters behind as it tries to find all the completions I’m not asking for. Company, flymake, eldoc are all intolerably slow when working with my codebase, and I have turned them all off or not installed them in the first place.
M-x termis really useful, but do not attempt to run something that will produce a lot of output to the terminal. It is near intolerable. Literally orders of magnitude slower to display than an xterm or any other terminal emulator. (M-x etermis no better.)The problem, of course, is that Elisp is simply not performant. At all. It’s wonderfully malleable and horribly slow. It’s been this way since I started using it. I had hopes for native compilation, but I’ve been running it for a few months now and it’s still bad. I love Emacs for text editing and will continue to use it. I tried to make it a “lifestyle choice” for a while and realized it’s not a good one if I don’t want to be frustrated all the time. Emacs never seems to feel fast, despite the fast hardware I run it on.
-
The performance was the reason for me to leave Emacs. I was an evil mode user anyways so the complete switch to (neo)Vim was simple for me. I just could not accept the slowness of Emacs when in Vim everything is instant.
E.g. Magit is always named as one of the prime benefits of Emacs. While its functionality is truly amazing its performance is not. Working on a large code base and repository I was sometimes waiting minutes! for a view to open.
-
What did you find slow on Emacs aside from Magit?
I actually use Emacs because I found it really fast compared to other options. For example, the notmuch email client is really quick on massive mailboxes.
Some packages might be slow, though. I think the trick is to have a minimal configuration with very well chosen packages. I am particularly interested in performance because my machine is really humble (an old NUC with a slow SATA disk).
-
To be fair it was some time ago and I don’t remember all the details but using LSPs for code completion/inspection was pretty slow e.g.
Compared to IDEs it might not even have been slow but similar. I however have to compare to Vim where I have equal capabilities but pretty much everything is instant.
My machine was BTW pretty good hardware.
-
lsp-mode became much more efficient during the last year or so. Eglot is even more lightweight, I think. Perhaps it is worth giving it another go.
I think there was some initial resistance to LSP in the Emacs community and therefore they were not given the attention they deserve.
-
-
-
-
Out of curiosity, were you using Magit on Windows?
I use Magit every day and my main machine is very slow. (1.5GHz 4 core cortex A53) Magit never struck me as particularly slow, but I’ve heard that on Windows where launching subprocesses takes longer it’s a different story.
-
but I’ve heard that on Windows where launching subprocesses takes longer
Ohh you have no idea how slow in a corporate environment. Going through MSYS2, Windows defender, with windows being windows and a corporate security system on top, it takes… ages. git add a single file? 20 seconds. Create a commit? Over a minute. It’s bonkers if you hit the worst case just right. (On a private Windows install, MSYS2 + Exceptions set in Windows Defender it’s fine though, not much slower as my FreeBSD laptop) I asked around and there is a company wide, hardcoded path on every laptop, that has exceptions in all the security systems just to make life less miserable for programmers. Doesn’t solve it completly, but helps.
Either wait an eternity or make a mokery of the security concept. Suffice to say I stopped using Windows and Cross-Compile from now on.
-
-
With Windows I think it’s it’s particularly git that is slow, and magit spawns git repeatedly. It used also to be very slow on Mac OS as well because of problems with fork performance. On linux, it used to be slow with tramp. There are some tuning suggestions for all of these in the magit manual I think.
-
Nope on Linux. As mentioned our code base is big and has many branches etc. Not sure where exactly Magit’s bottleneck was. It was quite some time ago. I just remember that I found similar reports online and no real solution to them.
I now use Lazygit when I need something more than git cli and it’s a fantastic tool for my purpose. I also can use it from within Vim.
-
-
Working on a large code base and repository I was sometimes waiting minutes! for a view to open.
This happens for me as well with large changes. I really like Magit but when there are a lot of files it’s nearly unusable. You literally wait for minutes for it to show you an update.
-
-
I know you’re not looking to customise much but wrt. terminals, vterm is a lot better in that regard.
-
I actually switched to
M-x shellbecause I found the line/char mode entry in term-mode to be annoying (and it seems vterm is the same in this respect). shell-mode has all the same slowness of term-mode, of course. I’ve found doing terminal emulation in Emacs to be a lost cause and have given up on it after all these years. I think shell-mode is probably the most usable since it’s more likeM-x shell-commandthan a terminal (and that’s really its best use case).-
If you need ansi/curses there’s no good answer and while I like term it was too slow in the end and I left. I do think that for “just” using a shell that eshell is fine though.
-
-
-
-
-
I use the emacs-plus1 package. it compiles the version you specify. currently using emacs-plus@29 with
--with-native-compfor native compilation, and probably some other flags.-
-
Awesome! also, check out
pixel-scroll-precision-modefor the sexiest pixel-by-pixel scrolling. seems to be a little buggy ininfo-mode, can’t replicate withemacs -Qthough, so YMMV.
-
-
-
-
I’m a Mac user and I found it very hard to compile Emacs.
This might be a good starting point however:
-
I honestly don’t know I use nix+home-manager to manage my setup on macos, this is all I did to make it work across nixos/darwin:
Added it as a flake input: https://github.com/mitchty/nix/blob/7e75d7373e79163f665d7951829d59485e1efbe2/flake.nix#L42-L45
Then added the overlay nixpkgs setup: https://github.com/mitchty/nix/blob/7e75d7373e79163f665d7951829d59485e1efbe2/flake.nix#L84-L87
Then just used it like so: https://github.com/mitchty/nix/blob/6fd1eaa12bbee80b6e80f78320e930d859234cd4/home/default.nix#L87-L90
I gotta convert more of my config over but that was enough to build it and get my existing ~/.emacs.d working with it and speedy to the point I don’t care about emacs slowness even on macos anymore.
-
-
Do you use the jit branch of emacs?
Yes. I’ve been using the libgccjit/native compilation version for some time now.
-
-
-
-
Here you go. It changes a little bit here and there with some experiments.The packages I currently have installed and use are: which-key, fic-mode, counsel, smartparens, magit, and solarized-theme. There may be a few others that I was trying out or are only installed for some language support (markdown, yaml, and so forth).
-
-
Quick addendum on the config: that’s my personal config, which morphs into my work setup. My work one actually turns off flymake and eldoc when using eglot.
-
-
Is there anything that has prevented a Neovim-style rewrite of Emacs? A Neomacs?
I keep hearing about the byzantine C-layer of Emacs and the slowness of Elisp. And Emacs definitely has the community size to develop such an alternative. Why do you think no one has attempted such an effort? Or maybe I should add “recently” to the question. As I know there are other Emacs implementations.
-
As crusty as Emacs source can be, it’s nowhere near as bad Vim source was, which was a rat’s nest of
#ifdef. That’s why Neovim had to basically rewrite their way to a fork. The Emacs implementation is surprisingly clean, as long as you can tolerate some of the aged decisions (and GNU bracing). -
There is Climacs, which isn’t exactly the same, but is close.
The problem for any new Emacs clone will that it has to run all the Elisp out there. Unless there is a substantial speed improvement to Elisp or a very good automatic translation tool, any such project will be doomed from the start.
-
-
-
I have worked in go for 6 years and it’s been catalytic to my career. I am the go expert at my current job. It’s a fine tool for what you need it to do; but the real problem is that too many people treat it literally like Java. There’s pointless abstractions in codebases I’ve seen. There’s patterns from other languages wholesale pulled in just because it felt nice. Kubernetes is a perfect example of Gova.
Honestly after using Go for so long I’m learning Zig for low level and operating systems programming. Zig requires you to manage your own memory, but at this point I’m really okay with that.
-
-
The BourneShell was written in C using macros to make it look like some variant of ALGOL. I’ve never forgiven that guy after having a job debugging it.
-
So true. At my current job I’ve seen “XYZBuilderFactory” stuff in Go and all kinds over over-complex constructs. I love the simplicity that Go offers and despise useless complexity more and more by each day. Software needs to be as simple as possible to be maintainable and extensible. Juding the author of this article by his text he must be my anti-hero.
-
-
Nice. I once made something similar: a static blog generator which uses Github Issues to write blog posts and Github Pages to publish them. You can see an example and introduction here. The tool and the manual are on Github.
Didn’t want to hijack. Just thought maybe you are interested since your project looks similar.
After I learned about “ci” in vim I got hooked. All of the sudden replacing text in quotes became as simple as ci” and now I’m having a hard time to use other editors. Sometimes a little detail is all that it takes.
This was extremely helpful thanks.
Just to clarify to others. In vim if you are on a word “c” starts a change and the next keystroke determines what will be changed. For example, “c$” removes text from where the cursor is to the end of the line.
Now what is new for me is vim has a concept of “inner text”. Such as things in quotes, or inbetween any two symmetric symbols. The text between those two things are the “inner text”.
For example, in this line, we want to change the “tag stuff” to “anything”.
Move the cursor anywhere between the quotes and type ci then a quote and you are left with
This is a good example of why to me learning vi is not worth the trouble. In my normal editor, which does things the normal way, and does not have weird modes that require pressing a key before you are allowed to start typing and about which there are no memes for how saving and quitting is hard, I would remove the stuff in the quotes by doing cmd-shift-space backspace. Yes, that technically is twice as many key presses as Vi. No, there is no circumstance where that would matter. Pretty much every neat Vi trick I see online is like “oh if you do xvC14; it will remove all characters up to the semicolon” and then I say, it takes a similar number of keystrokes in my editor, and I even get to see highlight before it completes, so I’m not typing into a void. I think the thing is just that people who like to go deep end up learning vi, but it turns out if you go deep in basically any editor there are ways to do the same sorts of things with a similar number of keystrokes.
There is not only the difference in the number of keystrokes but more importantly in ergonomics. In Vim I don’t need to hold 4 keys at once but I can achieve this by the usual flow of typing. Also things are coherent and mnemonic.
E.g. to change the text within the quotes I type ci”(change inner “) as the parent already explained. However this is only one tiny thing. You can do all the commands you use for “change(c)” with “delete(d)” or “yield(y)” and they behave the same way.
ci”: removes everything within the quotes and goes to insert mode di”: deletes everything within the quotes yi”: copies everything within the quotes
d3w, c3w, y3w would for example delete, replace or copy the next 3 words.
These are just the basics of Vim but they alone are so powerful that it’s absolutely worth to learn them.
Just a small correction; I think you meant “yank(y)” instead of “yield(y)”.
Haha yes thanks I really got confused :)
And if you want to remove the delimiters too, you use ‘a’ instead of ‘i’ (I think the logic is that it’s a variation around ‘i’ like ‘a’ alone is).
Moreover, you are free to chose the pair of delimiters: “, ’, {}, (), [], and probably more. It even works when nested. And even with the nesting involves the same delimiter. foo(bar(“baz”)) and your cursor is on baz, then c2i) will let you change bar(“baz”) at once. You want visual mode stuff instead? Use v instead of c.
This goes on for a long time.
One difference is that if you are doing the same edit in lots of places in your editor you have to do the cmd-shift-space backspace in every one, while in vi you can tap a period which means “do it again!” And the “it” that you are doing can be pretty fancy, like “move to the next EOL and replace string A with string B.”
Sublime Text: ctrl+f search, ctrl+alt+enter select all results, then type your replacement.
Yeah I just do CMD-D after selecting a line ending if I need to do something like that.
What is a command-shift-space? Does it always select stuff between quotes? What if you wanted everything inside parentheses instead?
You can do it that way in vim too if you’re unsure about what you want, it’s only one keypress more (instead of
ci"you dovi"c; after the"and before thecthe stuff you’re about replace will be highlighted). You’re not forced to fly blind. Hell, if your computer is less than 30 years old you can probably just use the mouse to select some stuff and press the delete key and that will work too.The point isn’t to avoid those modes and build strength through self-flagellation; the point is to enable a new mode of working where something like “replace this string’s contents” or “replace this function parameter” become part of your muscle memory and you perform them with such facility that you don’t need feedback on what you’re about to do because you’ve already done it and typed in the new value faster than you can register visual feedback. Instead of breaking it into steps, you get feedback on whether the final result is right, and if it isn’t, you just bonk
u, which doesn’t even require a modifier key, and get back to the previous state.It is context sensitive and expands to the next context when you do it again.
Like I appreciate that vi works for other people but literally none of the examples I read ever make me think “I wish my editor did that”. It’s always “I know how I would do that in my editor. I’d just make a multiselection and then do X.” The really powerful stuff comes from using an LSP, which is orthogonal to the choice of editors.
I do not disagree. For vim, as for your editor, the process is in both places somewhat complex.
Like you I feel I only want to learn one editor really well. So I choose the one which is installed by default on every system I touch.
For which I give up being able to preview what happens and some other niceties. Everything is a tradeoff in the end
In a similar way, if you want to change the actual tag contents from “Stuff” to something else:
you can use
citanywhere on the line (between the first<and the last>) to give you this (|is the cursor):Or
yitto copy (yank) the tag contents,ditto delete them etc.. You can also use theatmotion instead of theitmotion to include the rest of the tag:yatwill yank the entire tag<tag style="tag stuff">Stuff</tag>.Note that this only works in supported filetypes,
html,xmletc., where vim knows to parse markup tags.I really like that I keep stumbling on tidbits like this one that continue to improve my workflow even further.