I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged.

The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect.

90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for.

Seen as a support it is important for the text editor to be as unobtrusive and responsive as possible, to not break the thread of thoughts. And slowness, even micro-stutters do that. Mastering the keyboard, which include knowing shortcuts, touch typing and generally typing fast also helps, so you think more about the problem and less about the keyboard when writing down your ideas.

Now, if the way you code looks like you are meditating in front of the screen, not typing anything but the final solution, and I am sure some people do, then you probably don't need to work fast in the editor. To each his own, but personally, speed is an important factor in choosing a text editor. That's why I am currently on Sublime Text and not VS Code. Even though the latter is similar but free, more popular, and with interesting features, Sublime Text is faster, and I like speed. And may take a look at Zed, now that it is available on Linux.

First of all, there’s the ease with which I can get those ideas out of my mind and into working code. If I’m fiddling with a mouse and dragging things around in some virtual 2D space, it adds cognitive load and puts my mind in the wrong mode for coding. When I’m editing in vim, it’s easy to get into flow.

There’s also the case that when I’m planning my solution, I’m also using a text editor with vim bindings, so I can get into the same flow state more easily as I’m doing software design.

And even though a coder might only produce an average of ten lines of code per day, that doesn’t mean I’m producing 10 lines each day. Some days I produce none, and other days I produce a hundred, so it makes sense to optimize for the days when I’m producing a hundred.

Beyond that, even the idea of producing a line of code seems to assume that you’re only writing new code. I’d say that 70-80% of my coding is refactoring. I’m either refactoring existing code or refactoring the code I’m writing as I go. The ten lines I write in a given day may have been written as thirty lines in the first draft, then edited down. So, again, optimizing for flow here makes sense.

- code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc.

- I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished.

- 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc)

I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.

In my normal process (not exploratory work), I don't write a single character until I'm sure of how the thing I'm making will fit into the overall design (such as the API it will have, how it will interact with other components, its placement in the overall architecture, what its responsibilities are and how to structure it so as to minimize potential confusion and make what it is doing clear to a reader, mentally walking through code paths to make sure other components can use it as intended, etc). All of that happens in my head, not in an editor (although I might have a few notes jotted down if it's a big change or a whole new feature).

Then, once I know exactly what I intend to write, I just dump it all down into the source files. 80% of it is already "finished code" in that I won't be changing it again unless I've made a serious design error.

Ten lines per day?? Over my 20-year career in Big Tech I figure I've averaged about 10 lines of shipping code per week. I've been working in a domain-specific field and have shipped several kernel features. These days I'll sometimes go an entire quarter without writing a single line of code.

Not all of us went down the "Java code monkey" career path.

> 90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for.

So you're saying that 10% is spent typing, which doesn't seem a silly amount to optimize for?

There’s a marginal difference between an editor where you can type quickly and one where you can only type fast.

We’re not talking about the difference between 300 wpm and 10 wpm.

I bet if you measured, you would see, at best, a marginal difference between the speed of input between editors.

Ie. The point is that, that marginal difference probably has no meaningful difference in your productivity.

What makes the difference is probably how it affects, for example; flow.

If your flow is interrupted by the editor hanging or waiting for some bs lang server lag, or having to update a vim plugin, you are being interrupted.

…and studies show that interruptions do have a meaningful impact on productivity.

This is why editors that let you type fast do not improve productivity for everyone. Some people get flow in other ways.

Fast typing is not a universal metric for productivity, and it’s absolutely a diminishing returns thing to optimise for.

It’s probably fair to say that if you have a moderately fast editor, going to a super fast editor makes no difference to most people.

…but going from an editor that freezes or forces you to spend your time upgrading plugins, probably does; because interruptions like that are probably universal flow destroyers.

With Copilot, this has become even easier because it is very good at guessing the relevant boilerplate to insert without needing to look through different options.

There are plenty of other areas where typing efficiently facilitates thinking about software.

- Writing clear notes and design documents helps in developing ideas.

- Writing documentation.

- Writing commit messages and issue descriptions.

- Writing emails and messages when communicating with others.

Typing efficiently is only one factor here, communicating clearly and efficiently, reading comprehension… these are also important. But typing slowly impedes development of those related skills as well.

It's not always the case. Quite often the only way to investigate the issue is to run a cloud workload that takes several minutes to start. Still, if you write good code, you can try to isolate the issue for local debugging at some point.

Just my personal experience, it's not about how fast I can get my ideas down in writing (whether code or not), it's about how often I am broken out of the flow when typing.

At one extreme, using your stats above of "10 finished lines of code per day", you could argue that using this keyboard (https://www.youtube.com/watch?v=9BnLbv6QYcA) should have no effect on your productivity, and yet no developer would make or support this argument.

Small frictions add up; there's a joelonsoftware post that I read a long time ago about this[1], and it stuck for 24 years!

The best editor/environment is the one that gets out of my way. One where I don't need to look things up on google. One in which I have already learned all the shortcuts, and don't need to relearn them to make the software useful.

Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing, and then look it up again in a few years when that extension is no longer supported. Same for Vim commands.

Using VS Code, or a full-fledged IDE[2] removes the whole command interface: I now need to remember dozens of key-chords, not a handful of verbs and a handful of nouns. I need to remember which menu, and which submenu needs to be clicked.

Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens!

The "keyboard maximalism" isn't about speed == productivity, IME. It's about "friction == disruption".

--------------------------------------------

[1] From https://www.joelonsoftware.com/2000/04/10/controlling-your-e...

> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don’t seem to care about the magnitude of the event, only the quality.

> And I started to learn that the days when I was happiest were the days with lots of small successes and few small frustrations.

[2] Which I use daily, btw. I'm not knocking the developers who use IDEs.

> removes the whole command interface

`C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs. VS Code (and many other Editors, like Sublime Text) has the same "keyboard only" usage possibility as Emacs.

I've switched from Emacs (after more than 20 years) to VS Code to Sublime Text and did not need to change my habits. And to be honest, Sublime Merge is what Magit always wanted to be, a useful combination of GUI (for the "easy stuff") and a textual interface for git.

I slightly disagree with this assertion. I upvoted you anyway because I think it's mostly correct for those who aren't full into Emacs :-)

My reason for disagreement: `M-x` in Emacs gives you access to every single thing that the editor can do (like the function to move the point forward with `forward-char`). The `C-s-p` in VSCode doesn't give you the same.

And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.

> Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens!

No. It happens only because you're used to Emacs and Vim, and unused to an IDE.

> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up.

And those frustrations are rampant in the Emacs/Vim world. People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

By the time I've done my coding, project-wide refactoring, and looked up half of a project's code most Emacsers/Vimers are still stuck trying to find all references with a full-text search.

There's a reason VSCode's LSP took the world by storm

It's one command that implements autocomplete which gives you access to the entire system.

> It happens only because you're used to Emacs and Vim,

That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.

> and unused to an IDE.

Objectively not true, if you had read the entire comment.

> People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

I think you have a chip on your shoulder about this. You read my post as some sort of attack on IDEs so responded with an attack of your own.

My point was about little frictions all adding up. Sure, there's a steep learning curve in learning a programmable editor, but you only climb that curve once.

It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts for similar functionality in Jetbrains/Eclipse/Vs/VSCode/etc.

I'm just explaining why needing to remember fewer things is the path of least resistance for me; whatever argument you are talking about involving signs of great programmers is beyond the scope of what I am saying.

And you know this command how? You discovered it how?

> That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.

Indeed. And now you complain about friction in IDEs because you refuse to learn IDEs to the same extent.

> My point was about little frictions all adding up.

Yes, yes they do. And I find there are significantly more frictions in Emacs and Vim than in a modern IDE. The only reason you don't see them is that you've already learned Emacs/Vim

> It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts

Wat. I don't even know what these random numbers mean, and where you got them from. And how we went from functionality and capabilities to navigation.

> I'm just explaining why needing to remember fewer things

Thing is, you don't remember "fewer things" with Emacs/Vim. You end up remembering about the same, or greater number of things on top of significantly worse functionality.

Like you pretend that remembering dozens of various commands to type into `M-x` is somehow easier, and requires less memory than remembering the common shortcuts for common actions and falling back to Cmd+P(VS Code)/Cmd+Shift+A(Intelli J) to look up actions you rarely use.

Why make personal attacks on me, like this:

> you pretend that

I'm not pretending anything.

> Thing is, you don't remember "fewer things" with Emacs/Vim. You end up remembering about the same, or greater number of things

Not true. Like I said, I use an IDE daily, and there's much more to remember to get the same functionality that I get out of (for example) Vim. It's easier for me to remember (for example) 10 nouns that can be combined with 10 verbs than to memorise 100 shortcuts.

You may find it easier to memorise 100 shortcuts rather than 10 verbs and 10 nouns, but I am certainly not pretending when I tell you that I find it easier to remember 20 things rather than 100 things.

1. There are no nouns or verbs in Vim. There's a haphazardly built combination of letters that are laboriously explained as some grand design.

2. You keep coming up with random numbers that make no sense and pretend (yes, pretend) that they are somehow true and relevant

I didn't memorise 100 shortcuts.

The only reason you struggle to get the same functionality out of an IDE is that you don't want to invest as much time and energy into learning it as you did with emacs/vim. There's nothing inherently easier about memorising `M-x sql-connect` or 20 random letters in Vim than learning basic functionality and shortcuts of an IDE.

> Thing is, you don't remember "fewer things" with Emacs/Vim. You end up remembering about the same, or greater number of things on top of significantly worse functionality.

You don't understand vim yet you confidently state that it requires remembering more things. vim is like a language. You do not memorize entire English sentences when you choose to communicate with someone, it's the same in vim. You do not memorize how to do do something, but rather the grammar/verbs/nouns.

If you know that 'd' is the verb for deleting, and that 'w' is the motion for 'word', you can combine them into 'dw' to delete until the end of the word. When you later learn that '$' takes you to the end of the line, you know that you can do 'd$' to delete until the end of the line. You do not need to memorize 'd$' and 'dw' individually, just the motions and actions separately.

The same applies to actions, when you learn that y is yank (copy), you can apply the same 'w' and '$' motions in that cases to copy until the end of the word/line. That is what the poster means about verbs and nouns. Vim isn't discoverable, you cannot learn to use it without reading. But it is the most logically consistent "editing language" I have personally seen (alongside kakoune/helix).

You are also mixing up many concepts in your arguments. You can get LSP in vim/emacs and you can get vim-ish hotkeys in popular IDE's. The topic of this thread, Zed, is pretty vimmy and is closer to vs-code than it is to vim.

> When you later learn that '$'

> when you learn that y

As if that doesn't require you to remember things. In the end I always, without fail, see people consistently struggle with doing things in Vim that take a single shortcut (or an action lookup) in an IDE. Even people who've been working in Vim for years.

Because it's a nice little story about "oh, it's so easy to yank a word" because it's always easy to come up with the most trivial examples.

And this narrative about verbs and nouns falls apart even for trivial examples. E.g. the simple act of going to end of line, end of file, beginning of file are three different shortcuts that have little to no relation to each other. No worries, you just have to memorize them. Don't forget variations on shortcuts like yy and Y. And many other idiosyncrasies that don't fall neatly into the verb-noun narrative.

> Vim isn't discoverable, you cannot learn to use it without reading

Funny how the very same people who say this are hell bent on never learning IDEs.

> You can get LSP in vim/emacs

Yes, you can. There's a reason LSP never came out of emacs/vim world.

Why? The only reason I can think of for this to be true is when there is high risk in writing wrong code. For example, long compile times leading to a large sunken cost, or a lack of testing processes.

Unless you're doing R&D, only spending 10% of your "coding" time actually writing code seems very low, and you should try to optimize the processes that are lacking.

Hastily written, poorly justified or reasoned code has a much higher likelihood of having this flaw, so that’s why I would say you are wrong about this.

I hear people complaining a lot: "This is tedious. That is tedious." They have no control over their development environments. They write code once and whatever was produced in the process will be checked-in as is.

It is aggravating because there is this sentiment that it is fine to be incompetent. It is not.

Features like vim/emacs macros do way than increasing the speed of accomplishing a task. They are a way of converting O(n^k) manual tasks to a O(1) task. These are ways of doing lots of work in fewer steps.

This is if your work involves lots of text heavy lifting tasks.

Speed many times is just a unintended but a welcome side effect. Real value is in not doing manual drudgery.

In my present work at DevOps, I could say it’s true IF we only look at code.

When I was doing computational intensive simulations, I would write clearly 100 or more lines of code everyday.

But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me.

I still have a lot of hope for Zed.

But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.

Thank god we still have vim and Emacs.

Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.

Really my own issue with Zed is the crummy TS language server integration. Everything else is fantastic.

I would like some form of built in diffing, but for simple conflicts this is fine.

It's not a deal-breaker, but it is really annoying - I have to find the problem myself with no assistance from the language server. In fact, with hindrance from the language server because it's littering the code with completely spurious warnings of irrelevant "errors" that aren't.

I haven't tried coding in TS on Zed, so I can't comment on how the actual TS experience is.

I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.

I love the AI integration in Zed, it’s really smooth, pleasant to use, and well-integrated. I have a good experience pairing it with Sonnet 3.5.

The REPL feature is great as well and I totally see myself using that.

I agree on the collaboration bit though. I understand it’s one of the original premises and goals of Zed, however in order for it to really work well, I think you’d need to get everybody in your company to use Zed… which is honestly a “pretty tough” sell. I could imagine it making more sense if they had IntelliJ and VSCode plugins integrated with it, so the adoption could be more incremental.

That said, I agree that I definitely miss e.g. debugging support.

Collaboration, AI, chat, couldn't care less. Hopefully they can be disabled. I used Atom for a few years before they discontinued it. Yes, it was quite sluggish but otherwise it was usable, it had multiline editing and other sublime-isms, so I didn't have learn how to use an entirely new editor. If Zed can replace Sublime, Atom or VSCode for me that's great, otherwise I'll pass. I'm only using the basic code editor features, no git, no collaboration, no integrated terminal, no nonsense. Multiple cursors, PCRE matching and dark theme (preferably molokay) are a must.

They are now trying to do collaboration with ai to return money to investors but again nobody wants this.

That's why most editing tools should be open source and done by people passionate about it. The only company that managed to do paid editoes well is Jetbrains because their IDEs are actually much much better than the competition and much better than Zed.

[1] https://kate-editor.org/

[2] I must say here too that Nano is actually an underappreciated gem. It supports a lot more features than people generally imagine: syntax hilighting, line numbering, auto-indent, multi buffers, mouse support, keyboard macros, … it's actually a decent simple code editor!

[3] https://kate-editor.org/post/2022/2022-08-24-kate-new-featur...

Much more project management tools and more advanced IDE-isms. It's primarily for C++ but, of course, has all the LSP support of Kate.

You can follow definitions, visually set breakpoints, automatically lint your code, etc. But one of my favorite rare features is the Class Browser. Being able to visually see a class hierarchy is very valuable, particularly for GUI libs and stuff of that nature that really leans into inheritance.

I use it for mainly writing small Go programs in these days. Bigger projects are promoted to Eclipse.

I use vim to edit code, but I like copying and pasting paragraphs of prose with a mouse. I didn’t realize that until doing a lot of writing.

I've replaced unsaved files in Kate with obsidian.md personally, as there if there is somewhere I can type, I know it will be persisted to disk.

I find the Helix keybindings easier to learn because you see what text will be affected by any operation before you do it. And by using Helix I've found I've been able to pick up Vim keybindings as well so can use it on a server.

I think it would help if it didn't have such a jarring default colour scheme though.

[1] https://helix-editor.com/

But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it offering autocompletion, matching, fuzzy file picker, multiple cursors, LSP and go to definition, and other features with no or minimal configuration and the guarantee of stability and support (something that can not always be said when picking among the competing Vim plugins for same)

I've also toyed with emacs in the past and think I could like it for this reason, but ironically most other programming editors don't seem to be committed to the user's abilities as a programmer. I don't think it's nearly as easy/accessible/encouraged to program vscode, for instance. Self-documenting programmable programs like vim and emacs are so magical--- I hope they never go out of fashion.

helix looks like a passion project, so i thoroughly understand their wish to tend towards what they enjoy doing.

I very occasionally will add a plugin or tweak something (eg if I want a new snippet or something) but it's really not necessary to have a big complex config and I would say I spend well under 5 minutes per year on config.

I really wanted to like helix but there are a few really fundamental things that are really crucial to most of my workflows that were just missing (eg reflow text) when I tried it.

I also tried the "pure" config from scratch way but its just way too much work to maintain, esp if you want all the goodies. Also, not an expert in Lua so my config sucked. Simply better to use an existing, well-maintained neovim distro. I tried all of them and liked astronvim the best.

At the same time it’s been pretty frustrating to use an editor that is spending so much time building AI integrations, REPLs, and so fourth when basic things like cut and paste and common Vim motions still have so many bugs.

I’d love to see them prioritize getting the basics solid first.

I think you might be under the impression that what the GP is complaining about is having the default copy and paste go to the system clipboard.

This is not what is happening; in Vim all modifications are saved to the default register. Making the default register the system clipboard is annoying, because the following happens:

Insert a newline? Newline replaces whatever is in the clipboard.

Switch around two letters in a typo with `xp`? That text replaces the contents of the system clipboard.

Remove a word? Change a word? Add a new word? All replace the contents of the system clipboard.

Run a macro that changes things around? Nukes the system clipboard.

I don't think that 99% of developers want this behaviour. What they want is that when they explicitly copy something, it must be reflected in the system clipboard.

It's rare, in Vim, to not use commands. It is, after all, a command-oriented interface.

Any command that removes text or modifies text places the removed text into the default register.

> While I agree it’s less than ideal, at least you always know it’s going to happen if you are sort of familiar with Vim.

The problem with making the default register nuke the system clipboard is that almost all text editing commands are going to nuke the system clipboard.

I want to pay for Zed for what it is. I want to sponsor a new code editor. I have zero interest in paying for a SaaS collaborative editor.

I think Zed is wonderful, and would perhaps go back to it after it matures a bit. For what’s its worth the friction going from Zed -> Neo vim was quite seamless, and I’d expect going the other way would as well.

0: http://www.lazyvim.org/

I've been pretty happy with it, but other options are worth checking out (SpaceVim, NvChad, LazyVim, AstroVim).

LunarVim has finally deivered a working LSP/TreeSitter which I always only got half working or would break once I had it working, in my self-managed configs.

0: https://lpil.uk/blog/what-i-use-2023/#software

1: https://gleam.run/

I kinda had the same journey as the author except that I clinged to the terminal workflow he had leave behind. Choosing a Neovim distro was the solution for me.

This is true, but only if you're not using one of the ready made distributions. I didn't switch to NeoVim until I discovered LazyVim and this amazing guide https://lazyvim-ambitious-devs.phillips.codes/.

That changed everything. I just use LazyVim out of the box, as if it was a Jetbrains IDE. No config hassle, no issues with updates. It just works.

Regarding Zed:

It's a small niche they're trying to fill in a very competitive market. Currently they have the advantages of being the current cool thing. But that's not enough in the long run. If I would knew some killer feature, I'd go ahead and write it here. But that's the thing, I can't think of any. For simple, mainstream usage, VS Code is there. Ulimate IDE features: JetBrains IDEs. Ultimate productivity: LazyVim (or other NeoVim setups), ootb modal editing: Helix.

I got fed up of tweaking my own config and keeping up with the very fast moving plugin ecosystem. Gave LazyVim a try (after using LunarVim for a bit) and it's been a breeze. It's very well polished and maintained by a prominent plugin author.

Speed to open and general snappiness. Nothing comes close to Zed especially in larger codebases as most agree in the thread.

Till then, Sublime Text 4 is still the best non-terminal text editor I've ever used and I continue to daily drive it. Sure its paid and non-FOSS, but its incredibly performant on Linux and Windows and its LSP extension + Sublime Merge fill the gap left by VSCode for me. Well worth the price tag IMO.

It's essentially the same model used by other editors like the Jetbrains suite, but unlike Jetbrains, updates to Sublime Text (and Merge) are few and usually don't contain much other than bugfixes.

I've faithfully purchased Sublime Text licenses since the initial versions (switched over from Textmate), but as my ST4 license recently expired, it has forced me to review just what i get for the money i pay.

ST was excellent when it first arrived, and it's still one of the fastest loading editors out there, but pretty much every other editor has more or less caught up, including free ones like Zed and VSCode, making a recurring cost harder to justify.

The issue tracker for ST has 1863 open issues, or 41% open vs closed issues [2], and the issue tracker for SM has 1055 open issues [3].

I have no problem paying for software, and i understand that most developers don't work for free, but with this software it doesn't even appear i'm paying for "work", and instead it appears to be more or less a passive source of income for the developer.

As i wrote earlier, i'm not entirely sure what i'm gonna do, but given the slow pace of improvements to ST, i guess i can easily wait a couple of years before updating, if ever.

[1]: https://www.sublimetext.com/blog/

[2]: https://github.com/sublimehq/sublime_text/issues

[3]: https://github.com/sublimehq/sublime_merge/issues

I had seen some of the other "Neovim as IDE" projects but after looking at them carefully, I decided that LazyVim is generally the most polished one out there. Folke deserves a lot of credit.

The breakthrough for me was realising that it's a totally acceptable tradeoff to let other developers who know what they're doing, keep up with the bleeding edge plugin scene, and have generally good opinions make decisions about configuration so I can get real work done and not spend time getting bogged down in ricing and config files.

    -- lazy.nvim configuration example
    require('lazy').setup({
      defaults = {
        lazy = true, -- default to lazy loading
        -- other default options
      },
      plugins = {
        { 'neovim/nvim-lspconfig' },
        { 'hrsh7th/nvim-cmp' },
        -- ... other plugins
      }
    })

At this point, it supports most of the VIM subset that I care about, and I have added a number of new motions and modes that do clever things based on the AST. I am kicking myself for not doing this sooner and I think I need to write up a blog post about it. It's surprisingly easy.

1. e.g. https://marketplace.visualstudio.com/items?itemName=DCsunset...

The thing is that I used to consider headless Neovim to be the ultimate solution to "vim but with IDE conveniences" but I am no longer so sure. Keeping everything in sync between the two editors just seems like a task that's doomed to fail in many small paper-cut like ways. What I am doing now is much more like adding a few things on top but leaving VSCode in charge, letting it do its thing the way it was designed to.

  https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim

That has generally been my experience using VSCode, unfortunately.

> This extension uses a fully embedded Neovim instance, no more half-complete Vim emulation!

It's really the better (Neo)?vim extension in my opinion, but it has a lot less installs than the other popular extension, called just "Vim" (6.656M installs vs. 400K installs) that extension AFAIK actually emulates Vim in JavaScript, I used it for about a year in 2018, before the other extension "VSCode Neovim" was released in 2019 and remember not having a good experience using it then (to compare, the extension "Vim" was released in Nov. 2015).

I was seriously doubting the internal Rust engine (they don’t use rust-analyzer or LSP), so I switched to VSCode with the rust-analyzer extension, and the same happened there too, although no freezing. Turns out some of my types were 80k characters long, and ‘cargo clippy’ was taking ~900 seconds of one core pegged at 100% for rustc. Oops.

Now I know what they mean when complaining about super long compile times on Rust, and I wasn’t even doing async :)

I know Rust uses name/symbol mangling but what sort of type declaration in Rust ends up with that long names ?

I like having many projects open.

> Every now and then I would update a plugin in Neovim and everything would break, and I would have to spend time fixing it instead of getting work done.

Would be a problem anywhere there is a plugin system. Just don't go around updating kitchen sink without having the ability to rollback. Full on version controlling 3rd party plugins could be annoying (unless you use a plugin manager specifically with that support e.g. straight.el or elpaca in Emacs), but simply taking a dumb snapshot of plugin directory may also do the trick.

1. Zed downloads binaries without user input as soon as you open a file; think LSPs and linters. This is a hot topic and has been for a while.[0]

I would rather my editor break (or even better, fail gracefully and helpfully), than obscure what amounts to being a significant action that I believe warrants user involvement.

2. I can't tell what gets sent to Zed's servers.

I don't have time to audit all the code, but as an example, this PR, [Allow Al interactions to be proxied through Zed's server so you don't need an API key][1], has +3,628 -8,918 changes and even just by the title seems to suggest that using the Assistant feature may result in requests being sent to Zed's servers.

This is a dealbreaker for me because, not only is this not documented anywhere, it seems in contradiction to the EULA.

"User Content is transmitted from Your environment only if You collaborate with other Zed users by electing to share a project in the Editor. Once You share a project, Zed may transmit User Content consisting of file paths, file contents, and metadata regarding the code returned by language servers."[2] It doesn't mention if using the Assistant feature is part of the network based solution or that it's the same as "sharing a project," but I'm not an Editor-EULA lawyer.

Arguably, this is true is any open source project, though my stance is generally to be more alert to privacy concerns with software from newly-backed pre-profitable startups. I don't want to spend my rare editor-tweaking time on nonconfigurable privacy and security control workarounds.

Edit: As if on cue, another PR to seemingly default to sending data to zed.dev: https://github.com/zed-industries/zed/pull/16454

[0]: https://github.com/zed-industries/zed/issues/12589

[1]: https://github.com/zed-industries/zed/pull/7367

[2]: https://web.archive.org/web/20240718140959/https://zed.dev/e...

Granted I have a 10+ year old vimrc and rarely add new plugins, but saying Neovim is fragile is nonsense. Don’t install every new plugin perhaps?

But I do agree that vim's stability is priceless. It's been years without any need for major changes in my vimrc, and without any trouble with the plugins I use.

I'm sympathetic with the author, though. Whenever you need to change, finding an alternative that "just works" always makes things easier and you can quickly get back to being productive. I'm not so sure that I wouldn't go down a similar path if the vim ecosystem collapsed.

In my experience Neovim is very reliable, even when building off `master`, which I did for a couple of years.

It's true that Neovim leans more towards more changes and thus more risk of bugs, but claiming that Neovim is unstable is unfounded.

Plug 'alvan/vim-closetag' Plug 'ap/vim-buftabline' Plug 'davidhalter/jedi-vim' Plug 'dense-analysis/ale' Plug 'dstein64/vim-startuptime' Plug 'itchyny/lightline.vim' Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': { -> fzf#install() } } Plug 'junegunn/fzf.vim' Plug 'junegunn/vim-peekaboo' Plug 'machakann/vim-swap' Plug 'markonm/traces.vim' Plug 'mhinz/vim-signify' Plug 'preservim/nerdtree' Plug 'preservim/tagbar' Plug 'romainl/vim-cool' Plug 'simnalamburt/vim-mundo' Plug 'tpope/vim-characterize' Plug 'tpope/vim-commentary' Plug 'tpope/vim-fugitive' Plug 'tpope/vim-repeat' Plug 'tpope/vim-rhubarb' Plug 'tpope/vim-sensible' Plug 'tpope/vim-speeddating' Plug 'tpope/vim-surround' Plug 'vimwiki/vimwiki'

I don't think that's accurate. Now, if OTOH you said "the Lua kids" then I'd probably agree.

You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.

I can't take seriously someone, who says that Apple's stuff runs smoother (unless we are talking about useless animations).

However, it's not as ubiquitous on *nix systems as editors such as vi/vim. And for those of us who work with various infrastructures and deployment constraints, it's much easier to focus our efforts on an editor that is also ubiquitous. And vi/vim fits that mould.

In other words, while Zed is a vi-able alternative, I doubt most vi/vim users will switch to it exclusively.

I have switched to Zed, but it sadly shares more in common with vscode than it does vim. I believe the ideal text editor would bring a small amount of GUI to the general idea of one of the popular nvim distros (especially telescope).

People talk about not needing to type fast when coding, but I do need to navigate quickly, especially to not lose context while thinking. Ivy/Helm/Telescope with one of the various jump libraries (and LSP of course) makes code navigation feel second nature.

The issue for me was with the Docker LSP. I have a codebase where a Dockerfile is a Jinja Template. Zed’s syntax highlighting broke at the first curly braces. Both my Doom EMacs and LazyVim seem to have no problem with it. I couldn’t work beyond that point.

I didn’t expect it to highlight 2 languages. I just wanted the Dockefile parts to be highlighted. But Zed stopped any highlighting after the first curly brace, which produces inferior results compared to the regex (assuming) based highlighters out there.

I see what you're saying that other highlighters are continuing gracefully though.

Supermaven still has some issues on Zed, but apart from that its been rock solid and ive fully switched from Neovim.

I tried emacs but found the same issue with plugins. It's just hard to keep up and organize them, so far lazyvim is the easiest for me but not "easy".

I'll have to try zed if it's foss. I do wish that some "standardized" plugins would just be integrated into the base application or a new application like Neovim from vim. I don't know the history, so I'm not sure how it came about, but it does feel like there is some stagnation with some of the gnu/linux stuff.

In my career, I have used text editors including vim which I still very much enjoy and both Eclipse and IntelliJ when I used to code in Java which I also enjoyed.

VSCode seems to me to be as slow than a full IDE - too slow to be a nice editor - while having less features and an inferior UI to a full IDE. I don’t get it. Is it because so many languages don’t have a good IDE so people have come to accept the subpar editor+plugin experience?

https://www.reddit.com/r/webdev/comments/1euwht3/webstorm_is...

Most discussions I've seen, including that one, say that VS Code is slower than most lightweight text editors but faster than most IDEs (including WebStorm which is IntelliJ). I don't personally have experience with IntelliJ, but in my experience VS Code is very noticeably faster than Eclipse.

That linked thread also mentions that compared to IntelliJ, VS Code has better remote development, a less cluttered UI, better support for multiple languages in one project. And _many_ people mention the better performance.

Personally, running an open-source project with a lot of contributors who are young or from third-world countries, it also matters a lot that VS Code is free.

Even IntelliJ is noticably faster than Eclipse. This is a heavy indictment of Eclipse, not any other editors.

HOWEVER..

It has a killer feature if you are doing remote development.

It (mostly seamlessly) presents the remote (ssh, docker, wsl) as if it was local, and I've yet to see another editor do it as well and as cleanly.

So much so that when doing remote development I'm prepared to put aside VSCode's other shortcomings for the superior remote development experience.

For local development I still use vim+terminal, but if I'm in a situation where development needs to be done on a remote machine, the VSCode vim bindings are good enough that I'll probably be using VSCode.

There is also JetBrains Gateway which allows you to run IntelliJ/PyCharm/etc. remotely. I'm using it and it is very usable, however, there are occasional bugs which could be explained by synchronization issues

Btw. Vim should be very usable over ssh (especially with tmux and maybe iTerm2/other terminal integration with tmux' control mode - tmux panes are native windows, new terminal window/tab creates new tmux window/pane etc.). Why are you using VSCode over Vim for remote development?

Contrary to that they may find the ability to shape the editor using extension pretty nice, and doesn't care for having an IDE for every language they use. Its nice being in the same environment no matter what. Also the ability to ssh to another machine to edit and run code with the same experience as it was locally (in a gui) is pretty good.

Every shoe is sub par the wellington/rubber boot experience when it is raining, but you will see that most people do not wear rubber boots. People don't generally like to maximize their choices along one axis, so what can be seen as "sub par" is actually the overall best experience.

I never really tried the git integration as I use git purely through the CLI and didn’t try to work on a remote code base so I might have missed the killer features.

Pretty much does everything you would want whereas I have a bunch of problems with emacs and neovim that stop me using them full time. Ideally I'd use emacs but it has performance issues with my giant typescript codebase I work onfor my job.

I’ve seen people complain all the time about how slow VS Code is, and I haven’t really had that issue on an M1 Mac, at least not since some major perf work in VS Code a few years ago. And I know what a fast editor is — I’ve used Helix and minimally-configured Neovim for years.

I've worked on large front-end codebases. VS Code has much better TypeScript support than IntelliJ. I'd rather this not be the case because I much prefer IntelliJ.

People using VS Code are writing JavaScript/TypeScript/Python that doesn't need full IDE features. And VS Code is much faster than Eclipse / IDEA kinds.

I’m sorry but having used both. VSCode is not faster than Eclipse. It’s far less good at writing Java however.

You are not really answering my question by the way. So people are indeed using VsCode because there are no proper IDE for JS and TypeScript?

Yes, that's it. There are plugins for everything and mostly works. Not the biggest fan of it anymore tho so looking for my next IDE or develop one for my liking using AI.

After the initial setup phase where things were constantly added and tweaked, LSPs configured and so on I've not made any sweeping changes to the config in the last year and a half. I even changed jobs and languages halfway through and everything remained fairly consistent other than adding the new LSP.

Technical minimalism is a conscious choice, the same exact problem can come from vscode with fifty plugins and conflicting keybindings.