I guess you haven't used Sublime Text before?

Every little while, I try to make vscode my main editor, because I enjoy all the features. I always switch back to Sublime just because VSCode's slowness bugs me.

Haven't really tried Zed in earnest yet, though, because of no custom LSP support.

That and self updating in ways that broke my most important plugin.

VSCode complains and I’ve got to hardcode an alternative absolute path gemfile for Shopify’s LSP to work. It also feels clunkier, even on powerful machines.

If Zed can give parity with Sublime on the references (I just tried and it did not seem to find any references when clearly bars was there) might be an interesting change. Considering it’s open source now I’d happily switch as it does seems super quick.

I might also be old-man yells at cloud and the copilot integration doesn’t appear important yet, but current sublime support is pretty poor for it and seems like that’ll be a thing more and more.

I mean, Emacs, which can probably be considered the oldest code editor at this point, got built-in tree-sitter (which is what Zed uses under the hood) support in the last release. So it's not really related to editors being new or old

If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode), the autocomplete & intentions feel instantaneous.

I think the team has learned a lot from previous editor implementations (they were the core team of atom that was notoriously slow), and so they've had an opportunity to do a lot of stuff right.

FWIW they also are the team that originally wrote tree-sitter.

The quickness feels more like it's in the core of the editor. I was shocked how much it impacted the editing experience when I tried it in early beta.

Some more anecdata to back this up: initial workspace load in VScode I can watch RA tick through its progress. Clean and boot up Zed and the same process is so fast that it’s almost unbelievable.

I always thought the major slowness was coming from clangd itself, so I'm surprised and impressed to see that Zed appears to be quicker on this front. I might be using Zed as a 'second opinion' editor because of this.

However, now I'm used to the infinite customizability and coziness of Emacs, it's going to be hard for me to move across to Zed permanently.

[1] https://emacs-tree-sitter.github.io/syntax-highlighting/

[2] https://github.com/meain/evil-textobj-tree-sitter

I use python-ts-mode, rust-ts-mode, c++-ts-mode, bash-ts-mode and a few more right now and they work well.

You can write your own modes with it also, but I have not yet looked too deeply into this.

It's definitely usable today in emacs-29, but not every language has a tree-sitter mode yet.

Whoops my tab was outdated and I didn't see that others already replied.

But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.

There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck: I think it’s a front runner there. But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS.

At least that’s how I worked with my vim tmux sessions ;)

  emacsclient -ca '' 

  alias emacs="emacsclient -ca ''"

It starts up with ~77 packages in half a second.

This is my config.

https://gitlab.com/ideasman42/dotfiles/-/tree/main/.config/e...

This is going MIT as part of a bigger project in about a month (think Lucid s/C++/modern models/).

If I inline attribution you mind if I borrow this or that?

1.4 seconds for 100 packages, half of which are on probation? My (and soon `HYPER//MODERN`'s) package set is under heavy construction, I'll be sad if I don't get it under 300ms including loading and rendering a logo at 6k from a cold disk which that was.

Rust is a perfectly good language for writing tight code, but those `emacs` inner loops have been tuned by hard-ass pros for 30+ years in straight C, which is plenty fast too. Even the best Rust code doesn't have that kind of tuning in.

`emacs` is fucking fast.

I mean, it's not slow per se, but compared to vim it's noticeably slower so I can't deal with it.

To each their own, but for a hardcore Emacs user (wrote a number od my own plugins) that actually tried and couldn't seriously adopt VSCode for more than a few months, Helix was such a nice surprise + change of pace. Worth giving it a shot if you're caught in that gap.

It’s a 404 until I get to an RC, but aiming for March 1st on “hyper-modern.ai” for all MIT on emacs, nvim, and vscode.

Congratulations for winning HN sentence of the year before the end of January.

(Spoiler: https://github.com/bablr-lang/)

- gcmh -package and gcmh-mode and/or gc-cons-threshold variable (former should take over the latter)

- read-process-output-max

- jit-lock-defer-time

- package-native-compile

Doom Emacs sets gcmh in its initialization so tweaking that might not be needed there. You may still want to touch gcmh-high-cons-threshold and gcmh-idle-delay-factor. Here are mine currently:

    (setq gc-cons-threshold (* 1024 1024 1024))
    (setq gcmh-high-cons-threshold (* 1024 1024 1024))
    (setq gcmh-idle-delay-factor 20)
    (setq jit-lock-defer-time 0.05)
    (setq read-process-output-max (* 1024 1024))
    (setq package-native-compile t)

    (defun my-minibuffer-setup-hook ()
      (setq gc-cons-threshold most-positive-fixnum))

    (defun my-minibuffer-exit-hook ()
      (setq gc-cons-threshold (* 32 1024 1024)))

    (add-hook 'minibuffer-setup-hook #'my-minibuffer-setup-hook)
    (add-hook 'minibuffer-exit-hook #'my-minibuffer-exit-hook)

https://old.reddit.com/r/emacs/comments/bg85qm/garbage_colle...

Here is an interesting optimisation that was merged in master, but didn't make the cut for 29 in time. I thought it improved snappiness:

https://tdodge.consulting/blog/living-the-emacs-garbage-coll...

---

Anyway, I also have these in my init (I nicked these from Doom which I don't use but they have done a lot of work to dive deep into these things, mostly around what improves start up but the following might help in general):

    ;; if you don't use RTL ever, this could improve perf
    (setq-default bidi-display-reordering 'left-to-right
                  bidi-paragraph-direction 'left-to-right
                  bidi-inhibit-bpa t)

    ;; improves terminal emulator (vterm/eat) throughput
    (setq read-process-output-max (* 2 1024 1024)
          process-adaptive-read-buffering nil)

    (setq fast-but-imprecise-scrolling t
          redisplay-skip-fontification-on-input t
          inhibit-compacting-font-caches t)

    (setq idle-update-delay 1.0)

If I do inline attribution you mind if I borrow that under MIT?

Most examples you'll see of `straight.el`/`use-package` configurations will have some version of: `(use-package something-cool :ensure t :config ...`. The `:ensure t` clause will cause it to fall back on `package-install` in the event it's not bolted into your local Cargo-style-own-the-world-and-dont-break repo mirror. Disks are big, it's like the right default now.

But if you've got a package that's mis-specified in terms of where on `github` or wherever that `striaght` is supposed to find it, you can find it tapping `elpa.org` on the shoulder at a time when the UI thread is also doing blocking network IO.

The `Messages` and/or `straight` buffers will have warnings about this, so it's fixable to find the offending package and it'll stay fixed, but in fairness what you're describing is possible.

1: https://github.com/progfolio/elpaca

Please share how.

    ;; don't garbage collect based on cons count
    (setq gc-cons-threshold 10000000000)
    (defun garbage-collect (&rest args)
     (message "trying to garbage collect. probably you want to quit emacs."))

playing briefly with Zed it seemed like the terminal was a totally different "thing" than a normal file; i couldn't run the same text selection operations, couldn't split the window vertically or horizontally, etc. to me that loses a ton of the benefit of having a terminal in the editor in the first place.

still, it's a very interesting project. i have a very love/hate relationship with emacs, so i'm always interested in alternatives...

    (setq gc-cons-threshold (\* 100 1024 1024) ;; GC sometime after allocating 100Mb 
          read-process-output-max (\* 1024 1024)
          company-idle-delay 0.0 ;; company completions should be fast
          company-minimum-prefix-length 1
          lsp-idle-delay 0.1)  ;; clangd is fast
    (run-with-idle-timer 2 t (lambda () (garbage-collect))) ;; Trigger a GC after 5s of idle time

Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.

Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)

It ships with 29 and it's work to find `brew` or `apt` or `nix` or anything giving you less than 29.1 these days.

Have you tried a recent version? 29.1 is dramatically more accurate on everything from syntax highlighting to indention than VSCode (IMHO, they're probably either using or working on using `tree-sitter` too, those are serious people) or JetBrains stuff (they're working on their vscode clone more than IntelliJ these days).

I only use `nvim` for commit messages and stuff the last few years, but AFAIK it has all the `tree-sitter` stuff too.

If it's the sloppy naming of `c-basic-offset-this` vs. `py-indent-that` or whatever (I don't even remember), try a good baseline distro like Doom and tweak from there.

That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.

Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.

One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).

I can't parse this sentence -- could you unpack it? Not being a dick, I really want to know what you mean.

I work for a pretty conservative company re: GAI, and the ollama + continue combo made it through legal.

Yes, that was in seconds per keystroke.

The irony is that I moved from neovim to vscode because setting up intellisense in (neo)vim was always a hassle and never worked quite well. Pylance seemed too attractive not to give it a spin.

Now the lag has as mysteriously diminished, but still vscode is very far from being as snappy as (n)vim.

1) In Neovim, do `:TSPlaygroundToggle`

2) In Emacs, do `M-x treesit-explore-mode`

I really envy people who can sense passage of time between intervals of 5 milliseconds and 500 milliseconds.

My sensibility begins over a second. And to be honest even that is least of my issues. Same with start up time, I restart the IDE only once in a few days. I thinking spending a second or two extra for it is any where in the ball park of what I would call wasting time.

It’s very early, but I’ve been building a “trigger command/script and have it output anywhere” project that you could use as a bandaid solution.

I added Ollama support (you can specify model in settings)

https://github.com/jasonjmcghee/plock

It works wherever you are