Definitely go for GccEmacs (feature/native-comp) branch if you haven't yet. Despite being experimental, it's pretty much stable. I've been running it for over half a year as a daily driver, and seen zero issues (but much performance improvements!). Similar stories abound on-line.

Wish something be done about proper threading support, but I understand it's a herculean task at this point.

(For those unfamiliar, GccEmacs is a parallel branch of Emacs that uses libgccjit to compile ELisp straight to native code. It does it transparently - compiling in the background and then substituting bytecode-compiled functions for native-compiled.)

> Wish something be done about proper threading support, but I understand it's a herculean task at this point.

I would agree about adding concurrency and parallelism; but threading is very much a WorseIsBetter approach, which I certainly wouldn't like to use directly.

Co-routines or futures would seem a better fit for Lispy semantics. Actors seem too different and heavyweight, but I'd still prefer them to threading!

I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible.

What is the aim?

Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.

I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time?

Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that.

Edit2: are there good benchmarks for emacs to look at and play with?

The big things are indeed being outsourced to separate processes. LSP handles a lot, I also see some attempts at moving syntax highlighting to tree-sitter[0]. But all such work means a good chunk of code is running inside a foreign process, whose behavior cannot be easily inspected or modified at runtime.

But there are a lot of various smaller things in Emacs and elisp module ecosystem that would benefit from being able to run off the main thread. Emacs performance is fighting death by a thousand cuts, with almost everything being tied to the main thread (despite async features being used to pretend it's not).

--

[0] - https://tree-sitter.github.io/tree-sitter/

The inspection and modification is a strong point that I should have considered.

I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process).

I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process).

I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).

Do you know what makes it freeze? My gut would be that they did not set a buffer with a sentinel, such that even with threading, they would have still don't a blocking call there.

That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)

> Do you know what makes it freeze?

For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.

FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html

>you don't want to make a binary specifically for it

Most of the Emacs code I've seen that spawns a process spawns a short shell script: no custom binary needed.

I said "threading" as a catch-all term. Whatever makes Emacs able to fully utilize multiple cores of a CPU would work.

I get that; which is why I call out such things when I see them (I really hate threading!) ;)

I prefer vim as an editor, but in terms of being a unique and fascinating piece of software, emacs wins hands down. There's something really cool about the fact that you can't easily answer the question, "What is emacs similar to?", because it's such a total sui generis.

It's similar to a Lisp Machine.

Based on a few old mailing list it's apparently only very slightly so, and i'm not dissing emacs, it's just that the people who made lisp os and it's graphical layer really did allow users to augment and interact with most of the system in a very fluid and capable manner. Some examples from that mailing list (thread from the 90s or maybe even 80s) were still not present on a daily basis for code edition / versionning in the 2000s. Makes you wonder

As mentioned under another reply, take a look at evil-mode. Near-perfect vim compatibility as far as I can tell. Best of both worlds in my opinion!

Viper mode could give you the best of both worlds, depending on what you like about vim. If it's the key navigation, viper has you covered.

Hearing about Viper reminds me about the times where I was just starting to use Emacs, about 10 years ago! Fond memories :)

Since then, Evil-mode has effectively superseded it. I wish I had learnt vim-like editing a long time ago, as Vim-bindings seem to be mostly well-maintained in every editor.

Emacs-bindings are also in most editors, but it's not as useful since people (most people? in any case, me) usually customize the default shortcuts quite a bit. And less manpower to maintain them.

spacemacs has a very complete vim layer. By far it's the most complete implementation outside of actual vim I've seen.

Spacemacs uses “Evil mode”[1], which is available just as a regular (MELPA) package. I started with Vim and so I’ve always used evil. “Vanilla” emacs, spacemacs, now doom.

[1] https://github.com/emacs-evil/evil

I'm curious if you've already used evil with vanilla why you'd migrate to spacemacs or doom. I've never found either to add much that a custom config can't get to easily and with more control. Maybe that's changed in the past half-decade or so since I last tried Spacemacs, though.

The vim bindings are only one part of Spacemacs. The other (and I'd say most important) part is the SPC menu that exposes hundreds of keybindings in a discoverable, unobtrusive, and interactive interface.

Isn't that also just an elpa / melpa package though?

The keybindings are bound with evil and displayed with which-key, but the spacemacs special sauce is the keybindings themselves. There are probably thousands of them across all the optional layers. They're crowd-sourced essentially. So you don't have to set them up manually for each language/tool you work with, you just add the layer and get sensible defaults out of the box.

I guess so? And if the aim is to make something completely custom, that's fine. But the Spacemacs keybindings are very well thought out, the configuration is just as important as the feature itself.

I have a somewhat lengthy vanilla config, and I can tell you why I'm thinking about trying out Doom:

At work, I had to make some simple modifications in a go project. I've never done go before, so I had to google how to add support for it on emacs. There's always more than one choice, which one is the best maintained package? Is there an optional but ubiquitous plugin that will make it more enjoyable?

With Doom, you just add the go layer and you're good to go. I'm fine spending time setting up, i.e., a clojure config, since I use it all the time. It's well-spent effort. Not as much for a language I seldom have to use.

Spacemacs is indeed great, I used it myself recently. But I will say, it's no longer really actively maintained. The community has migrated over to ~~Spacemacs~ Dooom Emacs, which is very similar (still uses space as leader key and vim bindings everywhere). In my experience, Doom Emacs runs a lot faster too.

https://github.com/hlissner/doom-emacs

edit: Changeed Spacemacs to Doom Emacs, whoops.

Its true that many have moved on to Doom, but Spacemacs is absolutely still maintained.

> The community has migrated over to Spacemacs

I'm guessing you meant to say Doom Emacs there?

I did! Thank you for the correction. Editted.

I used emacs quite a lot, back in the day, and have switched to vim for now.. well, too long. Thing with vim is that I've never seen anyone using stock vim and keys, there's this whole layer of plugins and custom key bindings that make it so effective for any particular user. Would that translate to spacemacs at all? I've only glanced at it, but not sure if it supports Vim plug for example.

Stock Spacemacs is like a fully-tricked out Vim configuration, made by and for "plugin" junkies. Its leader-based keybindings are very well thought-out and discoverable since you get a small menu for the level you are at. For example <space> g gets you to the git submenu, if you forget that <space> g s gets you magit-status it will remind you there.

> Stock Spacemacs is like a fully-tricked out Vim configuration, made by and for "plugin" junkies.

That is a fantastic description of Spacemacs

Sincere question: if I already have a vim setup with all the plugins I like, and I switch to evil mode so everything more or less works as I had it, what does emacs open the door to that I couldn’t do before? Org mode I imagine is one piece. Is there anything else I should look at if I try it?

There are a few IMHO: magit [1] is a nice piece for Git. And there's vterm, if you wish to use a (usable) term or tmux/screen without leaving the editor, tramp mode [2] for remote files and last but not least ergoemacs [3] if you prefer the CUA style for generic commands (and reduce RSI). Oh, and forgot to mention helm [4] too...

[1] https://magit.vc

[2] https://www.emacswiki.org/emacs/TrampMode

[3] https://ergoemacs.github.io/

[4] https://github.com/emacs-helm/helm

I'm all set up with spacemacs and trying these out, thanks so much for the tips! So far so good.

I use pre-release Emacs with the nativecomp branch ("gccemacs") and Doom. Starts in 2.1 seconds and it's blazing fast. Definitely the best thing to come to Emacs for me in a long time, very exciting.

I can't wait for it to hit release so everybody can play with it!

I have built gccemacs a week ago. I didn't see much difference in speed and it breaks wanderlust... Are there things to know to get the speed (and yes, I've checked it was enabled during ./configure :-)) ?

Any warts when using it with Doom? I only recently switched from vim to Doom, and I love it, but it can be a bit laggy when using it with some of the C/C++ IDE features turned on.

It works very well with Doom, Doom has support for it and detects it's available and does everything for you. Just compile Emacs and run doom upgrade as usual.

are binaries available somewhere, i tried compiling it about year ago but quit after struggling with few dependencies.

Going on 25 years with Emacs. Lots of other things I've changed over the years, but still happy with Emacs and Postgres.

I wish to use Emacs, but those keyboard shortcuts do not make any sense for me.

Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest.

I do not mind keyboard shortcuts in gneeral and use them all the time, it's just those in Emacs are hard to learn/remember knowing that I wish to change them anyway .

I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it and thus it blocks me from moving forward with exploring Emacs deeper.

> Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest.

I've got a very custom Emacs keybindings/shortcuts setup but... Sadly it requires some hackery: basically there's the whole major/minor modes shenanigan where one mode's shortcut can take precedence over the other(s). And if you want to define your own shortcuts which take precedence, all the time, over everything else, you need to dig a bit deep. And then even deeper because invariably there's this or that minor mode you'll want to use where after all you won't want your own shortcut but that one of the mode.

> I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it

Sadly this is true. I've got I'd say about 100 lines of code related only to keybindings. Now, once set up, it's pure bliss. For example I've got mod+{i,j,k,l} to move the cursor around, anywhere (text, menus, anything). It makes even more sense than vim's hjkl (ijkl mimics the cursor arrow keys layout, which is more natural and ijkl is easier to type than hjkl too).

> ... and thus it blocks me from moving forward with exploring Emacs deeper.

I can understand that. I'd say the easiest would be to define your own minor mode as explained here:

https://stackoverflow.com/questions/683425/globally-override...

This should get you started: if you do it like in the answer and make sure they always take precedence you should be good to go and can deal with the gory details later on.

Well, if you already know vim keystrokes, just use Spacemacs. The big win is easy discoverability: using the space bar as a menu-starter, and when you find the command you want, it tells you what key stroke you could have used instead.

It's a good question, but asking someone who has used Emacs for 25 years... I'm pretty happy with them, and indeed, do my best to have them replicated in other software I use such as shells and browsers.

On the performance/stability of Elisp front, I just heard about remacs, which is a fork that's starting by porting all the C to Rust: https://github.com/remacs/remacs

Still in early stages, but I think that's one to keep an eye on.

I'd be much more interested in one of the CL rewrites, which could (1) run all of the elisp as efficient compiled Common Lisp, and (2) extend the customizability ot the deepest layers of Emacs.

Unfortunately, most seem to be relatively dead from what I've seen.

The rust re-write is not intended to bring performance benefits. Currently the Rust version is a massive downgrade in performance relative to the C nativecomp branch.

Most recent change is 7 months ago. I would not hold my breath.

I'm curious what sort of performance you are hit by. For me, it is mainly org source buffers that I did not flag as async.

That and tramp not working too well over crappy internet. :(

Tramp works a lot more reliably if you customize where Emacs puts your backups and autosaves, such that they're stored locally instead of remotely. The Emacs wiki has details on how to do that: https://www.emacswiki.org/emacs/BackupDirectory

The biggest problem I have with Tramp performance is much deeper, the need to open a new connection for every request - it makes integrating other modes with Tramp much more difficult than I would hope for (e.g. I tried to make kubernetes-mode work over tramp, and it mostly did, but each refresh had to reconnect, which would freeze the whole Emacs GUI for a second or so; thankfully kubel-mode has a more complete implementation that handles this gracefully).

I've had this in my config for a long time. Seems to make tramp work a lot better:

    ; use ssh instead of scpx mode for tramp
    ; this should work a lot better with ssh connection sharing
    (setq tramp-default-method "ssh")

This was problematic even with SSH multiplexing?

You still have this problem even with a control master setup with ssh?

I can't and don't blame tramp, per se. My internet has regular hiccups of being completely disconnected. Pretty sure that is not fixable. :(

Not by Emacs, but locally storing backups and autosaves means it only matters when you're actively reading or writing a file via Tramp.

Absolutely. It just sucks, as my build are so much faster on the remote machine. :)

That is, a lot of my remote editing is not just idle edits, but edit, run build, burn down compile output of tests and other items I'm working.

If I really want hell, I'll try and run lsp remotely.

None of this would matter, if I hadn't built up so much muscle memory from when I did have good internet and it did just transparently work.

I work in the medical field, which requires me to view large xml files and multi patient csv files with years of patient history. The CSVs contain embedded pdf strings that are long strings of bytes in the file. Emacs struggles to copy and paste, and move around in the large CSVs.

For the large XML files, I have to switch to fundamental mode, because it struggles to highlight everything, and sometimes the xmls are pure ass and are basically all on one line. I've written a python script that will prettify the xml because emacs locks up when I try to do that. My colleagues just tell me to use sublime text.

Ah, yes. Long lines are known bad. I will be excited to see anyone give a way to fix that with minimal impact on the rest of the system.

I'm curious why other editors don't trip as badly on long lines.

gccemacs works remarkably fine for such a big change, it does bite my poor x201 hard on the compiling phase (we're now as modern as lein clojure bootstrap :cough:) but it does bring speed improvements already.