Leaving Neovim for Zed(stevedylan.dev)
stevedylan.dev
Leaving Neovim for Zed
https://stevedylan.dev/posts/leaving-neovim-for-zed/
330 comments
It is true that most part of software development happens in the mind, but sometimes, the mind needs a support. Some use a pen and paper, some use specialized software, but for many, the text editor is that support. That's where they throw their ideas, sometimes in code, sometimes as a comment, or in a scrap file.
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.
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.
I agree that 90% of software development happens in the mind, but also that being a keyboard maximalist makes sense, at least for me.
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.
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.
> The average developer averages 10 lines of finished code per day
This is a ridiculous statement. Citation needed.
This is a ridiculous statement. Citation needed.
According to Stroustrup & co, it's less: They see a good dev optimistically writing 2k lines of finished non-test code a year, and that's when rewriting code ¹, so that checks out!
(To be clear, I'm joking and agree with your sentiment, but they really did say that in an official reply to the US gov)
¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...
¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...
Hopefully it's clear that:
- 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.
- 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.
Hmm... This might be where my process differs, I guess?
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.
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.
My process is in that case quite different. When working in Python I’ll typically write thousands of tiny snippets of code directly in the interpreter to check that simple things work as I expect. Those are gradually distilled into parts of a .py file with accompanying pytest tests. Then those are refactored into classes and separate files as needed. Overall, I think I type and edit way more than you :)
This is a relatively widely known claim, https://stackoverflow.com/questions/966800/mythical-man-mont...
It's debatable how accurate it is, but I think the ultimate productivity of developers is actually surprisingly lower than you would think.
It's debatable how accurate it is, but I think the ultimate productivity of developers is actually surprisingly lower than you would think.
Last I saw, the stat was 40ish per day. It's partially testable though. You presumably have a codebase at hand with a few contributors. Just git stat that code and average the lines changed by the top 5 contributors. Count deletions as "finished" lines of code too. Add in some auto-generated lockfiles and whatnot if you still haven't hit that 40 line-per-day mark. Report back if you're able to exceed it.
> This is a ridiculous statement
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.
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.
> I'll sometimes go an entire quarter without writing a single line of code
Then you're not a programmer anymore, you're something else.
Then you're not a programmer anymore, you're something else.
A software engineer.
I work on big tech and average far more lines of production code per day because where my project falls on this spectrum. The biggest thing that I've seen slow things down is scale (both size of codebase as well as users), followed by testing culture. This and a few other factors dictate the rate at which you invest in feature development. Not everything is a heavily undertested behemoth that has hundreds of millions of users. Therefore your experience may differ greatly from others and that means no one has the right experience. Even different roles within an organization making a common product can experience great variance based on subdivision (infra vs platform vs product vs security, seniority, etc).
>finished code
I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist
I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist
I think typing speed is important during bursts. If you can type out a function name really quickly (autocomplete also helps of course) then you can continue your thought process with less interruption than if you were slower.
> 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?
> 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?
Yes, quite so, but it probably has almost nothing to do with absolute typing speed.
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.
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.
It is important to be sufficiently fast at editing or else you will not revise what you wrote.
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.
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.
This is partly true, but there is a caveat: it's 10 lines of finished. In order to get there you would write and edit this piece of code many times over until it reaches the desired quality. And VIM is meant for "editing" code.
I have to disagree; average is not a good way to measure. I have written approximately 6,000 lines of code (including empty lines but excluding some generated code) over the past few weeks. Yes, I write design documents before coding, and most of the code is completed within a few days. I definitely spend a lot of time debugging, but almost all of those activities have been constrained to code. Test cases are very helpful in making the process clean. I use Neovim inside iTerm2, so all those activities are done within terminal. By maximizing productivity through the use of the keyboard, I can eliminate many dependencies, such as the mouse and multiple displays. I believe dependencies are a source of distractions.
Most importantly, writing helps thinking. When I am stuck, I just write random comments (which I delete later) in the editor to help me think.
Most importantly, writing helps thinking. When I am stuck, I just write random comments (which I delete later) in the editor to help me think.
I don’t touch type and I’m fully with you on speed doesn’t increase performance, but I have recently started writing c# after two decades of python and man the number of lines that you have to write before you get to the meat of the logic! So I think that 10 lines of code are only to expressive languages not globally
In fairness, I don't have so much experience with C#, but my experience with Java and OO-heavy JS codebases is that most of the boilerplate can be automated away without much problem - typing "cl<tab>" generates a class definition, and I can hit tab to jump between the different bits I need to fill in.
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.
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.
Learning to touch type is hard, but worth it. Once you learn, you'll realize the difference it makes.
It need not be hard. I learnt over the Christmas holidays using Kaz (https://kaz-type.com/)
Could you post an example of the boilerplate you are facing with? I’m sure it’s something that's perfectly avoidable.
>>I've not once held a job where my keyboard speed had a noticeable effect on my productivity.
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.
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.
It’s not just about typing out code even though being able to do that quickly is more valuable than you realize.
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.
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.
> 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.
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.
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.
> 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
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
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
> 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.
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.
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.
> It's one command that implements
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.
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 the antagonism? Programmable editors don't work for you, fine.
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.
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.
> It's easier for me to remember (for example) 10 nouns that can be combined with 10 verbs than to memorise 100 shortcuts.
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.
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.
> 1. There are no nouns or verbs in Vim.
Yes, there is.
Since your entire argument is predicated on a false premise, maybe you should stop digging at this point?
Yes, there is.
Since your entire argument is predicated on a false premise, maybe you should stop digging at this point?
I agree. Honestly, I’m proficient with vim/emacs, but I’ve been using JetBrains for ~13 years and don’t want to sound boastful, but I’m pretty sure I’ll run circles around non-trivial amount of vim users in terms of productivity/efficiency/raw text editing. The amount of time I’ve put in customizing my workflow is stupid. The false dichotomy that if you use IDE you must be point-clicking around menus is often repeated. I guess … know your tool of choice inside-out is what’s more important.
> > It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts
> 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.
> 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.
> If you know that 'd' ... and that 'w'
> 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.
> 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.
> 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
[...]
> 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.
> 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.
> `C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs.
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.
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.
I think this is a gross generalization.
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.
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.
It depends on what you work with. If you debug a complex issue you need to check many different setups to see whether your suspicions are right. Then, having a nice workflow where you sticky edit and run your code is quite important.
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.
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.
> 90% of software development happens in the mind.
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.
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.
I personally have a pipeline of multiple tasks I'm thinking about in background. It easily could take a week to get details in my brain. During coding I get already worked out tasks. Most of the time it's a final design. My colleagues considers me as a 10x developer. 10% coding looks very real in my case.
The highest risk in writing code is that the code written will have a negative value; i.e. it will incur more development cost over its lifetime than it will recoup via its intended effects.
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.
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 think more in terms of enjoyment than pure typing productivity. If I'm using a text editor that I found comfortable and fun, I am more likely to feel good while working. So a text editor is more like a chair -- the gain in productivity is indirect and maybe a little subjective.
I tend to keyboard minimalism myself: doing as little typing as is required to produce the code. I.e.: lots of keyboard macros. Thus reducing the cognitive load of typing to a minimum.
I initially loved Zed.
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.
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.
To paraphrase an old quote, "every new text editor grows until it is bloated with collaboration and AI features."
Thank god we still have vim and Emacs.
Thank god we still have vim and Emacs.
Except, as I understand it, the collaboration features were one of the primary things they wanted to do with Zed. So this isn't a case of bloat. The first blog post on the site is "How CRDTs make multiplayer text editing part of Zed's DNA".
I always wondered are people really doing this collaboration stuff. I tried it at the start of the lock downs era. But i quickly found it annoying, but maybe its because the implementation was just bad back then.
> Thank god we still have vim and Emacs.
Emacs has had AI since before it was cool again.
M-x doctor
Emacs has had AI since before it was cool again.
M-x doctor
Emacs[1] has been bloated with collaboration (gnus, etc) and AI features (doctor, lisp in general) for decades!
[1] Eight Megabytes and Constantly Swapping
[1] Eight Megabytes and Constantly Swapping
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacsI'm not getting the same results for ed?
$ whereis -b ed | cut -d' ' -f 2 | xargs ls -l
-rwxr-xr-x 1 root root 55504 Feb 22 2020 /usr/bin/edClearly it grew a lot in size since 1929. It doesn’t waste nearly that much space on my timex sinclair.
(To explain and thus ruin the joke, https://www.gnu.org/fun/jokes/ed-msg.html)
(To explain and thus ruin the joke, https://www.gnu.org/fun/jokes/ed-msg.html)
Alternative reply:
while :; do echo ?; done
But your emacs is still 5.89824 * 10^37 bytes in size like parent commenter, right?
I spent a few minutes trying to work out your pipeline. I think this is easier
ls -l $(which ed)[deleted]
Except Sublime Text ;)
I'm still happy with vim/nvim as daily work tools (also currently exploring kakoune and helix... because why not).
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.
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.
I don’t follow. The collaboration features have been part of Zed from day one. The recent addition of chat feels more like something the team wanted to use itself, so they never have to leave the editor any more, not a core focus of development.
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.
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.
Seconded. I'm loving the Zed experience, but having Javascript features provided by the TS language server gives a really bad experience; if I fat-finger a bracket then I get a bunch of TS errors about missing TS stuff littering the code, even though I'm not writing TS.
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.
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.
Doesn't highlight Perl so I'll pass until it does. Looks snappy otherwise. Back to VSCodium, I guess.
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.
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.
There are many great editors out there, some free some not. If a newcomer wants to break into the market, they need to add something new to the table. Understandably, in this day and age, it might be AI. Plus, they need to find a way to make money, offering collaboration and AI related feature might enable that.
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 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.
Zed also hastily went to v1. Simple things are missing such as labels to identify where a conpletion It's coming from when there are multiple completions with the same name. Also typescript types which are updated by an external process do not reflect unlike vscode.
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.
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.
Isn’t Zed open source now?
Same. I decided to just go back to Sublime Text.
Since many here are complaining about this, I’ll jump in here to say the contrary.
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.
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.
I think the trick of text editors/note apps has become such that every few years you have to look for something else. Especially the note apps - either it dies, or bloats up, or these days more often goes subscription route ALONG WITH other negatives.
This. I don't need voice chat features in a terminal based text editor.
A lot of editors are being discussed here but I see nobody has mentioned Kate (KDE's Advanced Text Editor) [1] in the conversation yet, so I'm doing it. Kate is a very mature and capable editor, and even if I only use it on Linux I'm glad to know that it is also available on macOS and Windows. It natively supports LSP and has much, much more to offer in terms of project management, support for build system, support for working with Git (it's actually the only Git GUI that I found to be usable), SQL databases integration, and of course, advanced editing features. I started using it a few years back after a very long text editor journey: on Windows a bit more than 20 years ago: Notepad, HAPedit, then Notepad++ ; then I got a Mac and used TextMate (which introduced me to powerful text editors) for a few years ; then I switched to Linux ~15 years ago and used Gedit for a few months before diving head deep into Emacs and stayed fully there for… 12+ years (I actually still use it from time to time, but it's less and less the case and most importantly I stopped doing everything in it including my email, social networking, IRC, etc.) ; and now for a few years I've mainly been using Kate (and Kwrite for quick edits + Nano [2] in the terminal or on remote hosts). I even contributed a few features [3] to the project, KDE developers are very welcoming!
[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...
[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...
I agree that Kate is a good code editor. I have tried more than a year ago when I still use KDE Plasma (now switched to Gnome). Honestly, I am happy that there is at least one GUI Code Editor from a big community that actually on par with some popular code editor (VS Code, Sublime, etc). Because I see that most code editors made by the Linux community are always lacking in features when compared to other popular code editors.
However, there are some things that make me not use Kate as my daily editor. One of them is the file browser feature which I find more complicated than its alternatives in Sublime Text or VSCode for example. In addition, the small number of plugins for Kate is also one of the reasons I do not use it.
Kate is the only even remotely close alternative to Notepad++ for me. Close enough that I maintain a personal fork stripping out all the stuff I don't use and modifying a few small things to my preferences (e.g. load/save sessions from file menu, no need for 'session manager'.
If you like Kate you should check out kdevelop. It uses Kate as a core and expands on it.
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.
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.
Yes, it's a great editor. It's one of the members of "Great, but Unknown Tools" group.
I use it for mainly writing small Go programs in these days. Bigger projects are promoted to Eclipse.
I use it for mainly writing small Go programs in these days. Bigger projects are promoted to Eclipse.
I’m using Kate to write posts on https://oilshell.org! After a detour through many other tools, it’s great to find something open source and high quality.
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 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.
After Kate was ported to Qt4, I was very impressed that it could handle extremely large files with no sweat. I don't use it, because I need a remote development capabilities and when compared to Neovim it simply lacks the plugin ecosystem and a large community driving it forward.
I've had issues with kate loosing unsaved files, as well as lagging on large files due to the automatic text wrapping
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'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 use kate a lot when I need to inspect a huge file. Love the built-in rainbow rendering of columns for a CSV. Definitely a solid editor considering it is free and open source. I haven't done any serious dev with it though.
Vim has also started to do the the rainbow thing for CSV recently (around version 9.1.672).
Kate can be great but it's riddled with bugs and advertised features that a completely broken(like sessions)
For me this feels similar to why I use Helix[1]. I used to use VSCodium and had tried to switch to Vim or Neovim multiple times but didn't manage because of all the plugin configuration to be able to program. Then I saw an HN post about Helix, started it up and it just worked and so haven't used anything else since.
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/
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/
Helix has been trying to implement a plugins system for like 2 years that should tell you everything you need to know about its future prospects
A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap.
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)
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 tried to use it for multicursor editing which I tried to enable in Vim via plugins and it sucked, but being a console editor didn't help much. So I'm still using vi/vim for console editing because it's installed everywhere.
My first multicursor experience is with Helix (it goes to show what it means to have it built in instead of trying to find plugins for it) so it may be unsatisfactory for people who have used similar functionality in other editors.
I use it in a very basic way - like change similar things on related lines - but it is a nice enough feature for me to mention it as part of the batteries included Helix experience. My main issue now that I am using Helix locally is that its keybindings are not well supported in other places I occasionally work (VSCode, Google Colab) and I keep having to mentally switch between vi/hx bindings. Not a hindrance enough to go back to vim though.
You may want to check helix.vim. it's a vim script that emulates helix
In fairness Helix provides a lot of functionality out of the box and features are gradually being added all the time. The lack of plugin system is not a problem for many people, and I’d rather they take their time and get it right. I certainly don’t think it’s the case that they’re “trying” and failing to implement plugins - it’s clearly going to happen when the time is right.
Big fan of helix and am in this camp. Used to have a bunch of plugins for neovim, but in Helix, honestly just haven't felt the need for anything besides what it comes with. It's a great editor.
I think you only miss (or at least I noticed this happened to me) a plugin system when you've engaged with the programmable side of your editor and then have to use one that isn't. I dont use/try to stay away from using (neo)vim plugins but I do like to pull out repetitive things into little snippets. I have things to manage my clipboard, pull up manpages in another editor tab when I put my cursor over a command and press a key in terminal mode, and a scattering of other quick useful tools. A lot of it's not reasonable to upstream, so it's a bit frustrating to me personally to use stuff that isn't programmable.
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.
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.
Many helix users have their own fork to scratch that itch. I do too, and it's nice, but of course a little more maintenance than a set of scripts
I think a big missing piece with writing what you want in Rust and recompiling the editor to activate your changes is that you're not able to work with it _live_. That is, I can use the vim (or nvim or emacs) GUI/text processing/IO/etc facilities interactively as I'm writing my snippets to see if everything works the way I expected. I can send lines/expressions to the lua/elisp compiler running in the editor that I'm _currently using to write the program_ to change how it works, _on the fly_. It's an integrated programming experience in a way that very few things are--- it's not just about programmability, but this circular thing that goes on with editors that really fully commit to it.
And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.
They already have Scheme based config files and I'd say it is simpler that Lua.
What are you talking about? It uses TOML for config files and some S-expressions for queries, which is actually a consequence of using tree sitter.
https://docs.helix-editor.com/configuration.html
https://docs.helix-editor.com/configuration.html
I should have specified internal config files for the runtime queries that you mention. Those are .scm files.
I wouldn't really count that as editor config. Every editor with treesitter support will have configs for treesitter, for instance: https://github.com/nvim-treesitter/nvim-treesitter/blob/mast...
My comment is in the context of 'their own Scheme implementation'. Since they already handle some .scm files internally it's not that wild to pick Scheme over other languages as the base for plugins. It's a power user editor, Scheme should not scare them.
It can't really be simpler than Lua, come'on. Maybe if you already know Lisp, but for people who know C-like languages (Java, Javascript, C++) Lua should be much more "obvious".
[deleted]
scheme is a group of languages, it doesn’t have its speed. some implementations are very quick. and quick-to-learn, too.
helix looks like a passion project, so i thoroughly understand their wish to tend towards what they enjoy doing.
helix looks like a passion project, so i thoroughly understand their wish to tend towards what they enjoy doing.
I mentioned speed because they're writing their own instead of using Chez or Gambit or something (which have taken a while to get into 'performant' territory). Writing and maintaining a fast(!) Scheme is hard. Having spent time with r5/r6/r7rs (many variants for the latter) and their quirks I'd honestly say Lua is simpler by a wide margin, but some of this is down to preference. The Lua execution model, if nothing else, is a lot easier to understand than call/cc for instance. And the language does force you to write things functionally, practically speaking. I'm also not a huge fan of syntactic macros. Also things like dynamic binding which, in fairness, are just SRFIs but end up being implemented by most Schemes. I do respect their willingness to do what's fun for them, though :) that's what it's all about.
Scheme makes sense to me (better semantics than Lua), but I'm surprised that they didn't choose an established and fast implementation like Guile.
Yeah, that was mostly my thinking. I like lisp!
I use Helix and don’t miss plugins.
If you're happy with Helix, do nothing, it you find yourself missing features, try this: https://lazyvim-ambitious-devs.phillips.codes/
I love Helix and used it a bit, but the lack of plugins (and thereby features) made me switch.
I love Helix and used it a bit, but the lack of plugins (and thereby features) made me switch.
I also heard about Helix and have been curious about it, for the same reason. If I’m going to learn Vim keybindings, it’s because I want to move fast. Tweaking configuration files for an evening is the exact opposite of moving fast.
The idea that you constantly need to tweak your config files in vim/neovim is a bizarre myth that seems to have sprung up because vim is so flexible that some people love messing about with config. You can just copy something like vim-sensible to give sensible defaults and get going - you absolutely don't have to do a bunch of tinkering. I have used vim and then neovim for 24 years now and most of my config customization I did more than 15 years ago when I decided to add a bunch of extra keybindings.
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 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.
Agreed. I've been using (n)vim for roughly 8 years now and only touch my config to put in bits of Lua I've hacked together to make my life slightly easier (~10 minutes every few months? I just do it as-needed). I use 5-6 plugins total. I think the most vocal users are probably responsible for the impression of constant churn, because they've got fancy tricked out configs loaded with alpha-quality plugins and probably do need to constantly update it. Nothing against doing that, but it need not be that way!
Yeah, there definitely seems to be quite a bit of churn for people who adopt the newest plugins, and I think that can lead to the impression that Vim and Neovim require constant configuration maintenance. I don’t think the churn is necessarily bad for people interested in spending a lot of time on their configuration because it means there’s a lot of experimentation, which eventually makes its way to the whole community.
Just use https://astronvim.com/. I haven't touched my config for more than a month. With astronvim community, other people do the hard work.
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.
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.
Give Helix a try. If you happen not to depend intensely on a few big IDE features it's missing, it's wonderful.
I’ve also recently switched (largely) from Vim to Zed and I also think that Zed is in many ways great.
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.
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.
Yeah I feel the same way. The fact that Zed uses the system clipboard as the default register in vim mode, for instance, made it impossible to use in practice for me -- having every yank replace my clipboard was a bit of a nightmare!
And then there's me that configs vim to use the system clipboard by default
Same. I can’t stand not having A clipboard for the entire OS
The `+` register is the system clipboard in vim already. What you're referring to is remapping the `+` register as the default register (in place of the 'unnamed' register, which is accessed explicitly as the `"` register) for some operations - typically yank and paste.
Yes :)
I don’t know. That feels perfectly reasonable for what I imagine is 99% of all developers, so while sad, I can imagine why that use case is not very high on their list of priorities.
> That feels perfectly reasonable for what I imagine is 99% of all developers, so while sad, I can imagine why that use case is not very high on their list of priorities.
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.
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.
I assume all of these are some special combination of keys/modifiers? 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.
> I assume all of these are some special combination of keys/modifiers?
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.
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.
You can have multiple things saved on your clipboard at once.
There is a setting for that.
[deleted]
To be frank I don’t the majority of us care about these collaboration features. We just want a way to write code that is performant but makes it easy to leverage existing language servers.
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 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’m actually in the opposite camp, I had left VSCode for Zed about 6 months ago and used it exclusively at work/personal projects. I’ve customized it extensively, and loved its approach to Vim integration. But in the last two weeks I’ve made the switch to Neovim (using a customized LazyVim [0] setup). I really like Zed but as others have pointed out they are not prioritizing features around REPL’s, AI, and collaboration while many core features are lacking. Vim Cut/Copy and paste being bugged, and html tags not closing drove me crazy over time.
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 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/
A couple years ago I got really tired of maintaining my own vim configs, like the author of this piece mentions (plugins and updates causing problems). I just wanted to get out of the business of maintaining my own configs, so I decided to try a bundle, and eventually ended up on LunarVim, with a small handful of "dealbreaker" config changes. As opposed to a basic vim and then a bunch of plugins and custom configs.
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.
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.
I had tried and failed multiple times to start using Vim (after using Vim binds for a while), and actually failed the transition right before my 6 month stint with Zed. It was actually this post[0] from the creator of Gleam [1] that brought LazyVim to my attention. I made a handle full of modifications, removing certain plugins and adding others. I'm very happy with the result. Its been two weeks of using it at both work and home productively.
0: https://lpil.uk/blog/what-i-use-2023/#software
1: https://gleam.run/
0: https://lpil.uk/blog/what-i-use-2023/#software
1: https://gleam.run/
I also settled on Lunarvim (ans stopped worrying)
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.
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.
> I also settled on Lunarvim (ans stopped worrying)
Then I have some sad news for you. :(
https://github.com/LunarVim/LunarVim/discussions/4518#discus...
Then I have some sad news for you. :(
https://github.com/LunarVim/LunarVim/discussions/4518#discus...
That's a bummer. Time to jump ships.
I guess concentration of efforts in this espace is a good idea.
I guess concentration of efforts in this espace is a good idea.
Big fan of LazyVim here. The default config does everything I need it to do.
> 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.
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.
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.
+1 for LazyVim
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.
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.
> 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.
Speed to open and general snappiness. Nothing comes close to Zed especially in larger codebases as most agree in the thread.
Speed to open and general snappiness. Nothing comes close to Zed especially in larger codebases as most agree in the thread.
Echoing similar sentiments that I'm optimistic for Zed to become more polished and stable.
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.
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.
My only gripe with Sublime Text is that they've changed to a "semi subscription" license model, where licenses expire after 2-3 years, and you essentially need to buy it again after that time.
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.
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.
I'm actually using an expired ST4 license, but as another user already mentioned, you can continue using the versions available to you while your license was active. This is fine for me because I find Sublime Text to be a better experience than VSCode and Zed.
I'm in the same situation. The upgrade price for Sublime Text and Sublime Merge is $152 whereas the full license is $168. As you say, it feels more like a subscription model. I'd renew if the discount was bigger. I can of course continue to use the versions released while my license was valid, but it would be nice to get bug fixes and new feature while still supporting the developers.
I wouldn't mind the license fee as much if there was actually any development going on, but for the past 3-4 years, there has basically been 4-10 months between releases, and each release has been more or less bugfixes and rewrites [1]. There has been 4 updates in 3 years.
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
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 love ST4 but I need to do a lot of remote editing - that is, editing a project on a Linux server. VSC is the only tool I’ve used where the remote edit “works” and it also seems to constantly have problems. I’ve tried things like rmate or SSHFS but they don’t work well. Do you have any advice on a ST4 solution for this? Thanks in advance!
I'm wondering if the author ever tried one of the many neovim distributions, which solve a lot of the problem they're describing. All of the plugins and integrations necessary are already set up to create a nice fully featured IDE-style environment. E.g. LazyVim, AstroVim or NvChad
After years of using Vim as a keyboard assassin, then Neovim (with a custom config initially based on kickstart.nvim), about a month ago I started using LazyVim. After test-driving the default config for just a few hours, I found myself nodding my head and saying to myself, "Yes, this is the way."
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.
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.
I tries LazyVim, but on every startup it nags me about version updates, and :x somehow takes 2-3 seconds extra as well. I don't live in the editor; vim is only useful to me if it starts up and quits instantly.
You can disable the update checker with a very simple config change.[0]
As for :x being slow, I'm not sure what that might be, it certainly isn't the case for me, it quits instantly. Try asking around in their support channels?
[0]: https://www.lazyvim.org/configuration/lazy.nvim (look for "checker" field)
As for :x being slow, I'm not sure what that might be, it certainly isn't the case for me, it quits instantly. Try asking around in their support channels?
[0]: https://www.lazyvim.org/configuration/lazy.nvim (look for "checker" field)
It sounds like you don't have lazy loading enabled. No way it should take that long to start up, and version updates shouldn't be that frequent.
I don't know how to enable it. It isn't mentioned on the config screen, though not very much is.
How much ricing have you done of the default config? Lazy loading of plugins is enabled by default— you shouldn't have to do anything. LazyVim handles lazy loading automatically; you don't need to manually configure anything. It should look like this:
-- 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
}
})Agreed. I use to switch on and off between vim, neovim and VS Code vim-keybindings until I found AstroVim. When I use AstroVim, I can modify what little I need to knowing the base and foundation is taken care of and I can focus on what matters.
The article specifically mentions following chris@machine, so I would assume that LunarVim was on their radar. But I agree, it seems odd that it wasn't mentioned in the article.
There is also spacevim, which is what I use for remotes when remoting with Zed breaks(which is still quite often at the moment).
Over the summer I got an interest in Kakoune and Helix and discovered a number of extensions for VSCode that enable modal editing(1), but not VIM-style per default. I got excited about this and ended up writing my own extension instead.
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...
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...
That's very interesting. Very cool to look at the source and see how simple it is. I may have just answered my own question, but I'm curious why you prefer this over the popular vim or neovim extensions, which have quite good coverage of vim features, and the neovim one even lets you use real neovim plugins because it is powered by a real neovim instance.
I was using the other vim extension for years. I had tried the neovim one as well a few years ago and I ran into so many bugs that I switched back after 1/2 day. I am sure it's better today, but I can see that there is still an open issue with folding, for instance.
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.
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.
Cool, thanks for the answer. Simplicity and predictability can definitely beat long feature lists.
I really enjoy using Zed whenever I can. It’s incredibly snappy and has a clean UI. I agree with some of the other sentiments in this thread that I wish that the developers would focus more on some core IDE features. If Zed had better Git integration and remote support, I could switch over to it full time.
For me it's the lack of support for more languages that is stopping me... But as I write this I just went to have a look and it looks like they've just added a whole bunch in the last few months!
e.g. https://zed.dev/docs/languages/dart
e.g. https://zed.dev/docs/languages/dart
If you want true Neovim in VSCode check out
https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim
Maybe you can clear up a little confusion on my part. I looked at that link and realised that for some weird reason there are two different versions of the extension by the same developer, and the one I had installed is the other one with 93K installs (not the one you linked above with 400K). What's up with that and why doesn't he just go with the better version of the extension; what are the differences?
I feel like using this extension is a little
buggy. Especially around undo / redo actions being captured in “format on save” type actions that happen thanks to jslint or other tools.
Yes I've tried to use the neovim plugin many times - but always run into some annoying bug, usually due to an interaction with another extension or VSCode feature. It has >400k installs though so it must be working for some people.
> but always run into some annoying bug, usually due to an interaction with another extension or VSCode feature.
That has generally been my experience using VSCode, unfortunately.
That has generally been my experience using VSCode, unfortunately.
they emulate the whole command / move / location layer in js ?
I think that's the usual approach for Vim mode in other editors. But this extension in particular:
> This extension uses a fully embedded Neovim instance, no more half-complete Vim emulation!
> This extension uses a fully embedded Neovim instance, no more half-complete Vim emulation!
No, they run a headless neovim process in the background and sync its state with vscode
To add to what sibling commenters have said, you can also configure this extension to use a specific Neovim binary on your system, and you can also configure it to use/load the same Neovim config you use when you use Neovim in the terminal. That's what I do.
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).
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).
"It just works" is precisely why I use Jetbrains products. I'm amazed they are not that common in many developer communities. They are amazing tools.
Personally, it’s because they are not open source and not as fast.
Yesterday RustRover became so unresponsive that the UI would freeze for more than 15 seconds (as reported by their exception notifications) and completions would take 5 seconds to appear and be wrong or lacking most times.
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 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 :)
> Turns out some of my types were 80k characters long,
I know Rust uses name/symbol mangling but what sort of type declaration in Rust ends up with that long names ?
I know Rust uses name/symbol mangling but what sort of type declaration in Rust ends up with that long names ?
A parser with Chumsky. There’s a lexer with logos too, but that’s simple and fast. Chumsy makes you create parsing functions which are chains of other parsing functions, and the types can become insanely long, if you don’t box some of them for erasure.
edit: to elaborate, it’s not that the type name was 80k characters, the type definition itself was, like TypeA<TypeB<TypeC, TypeD>>, TypeB<TypeE, TypeF<TypeG…>>>
edit: to elaborate, it’s not that the type name was 80k characters, the type definition itself was, like TypeA<TypeB<TypeC, TypeD>>, TypeB<TypeE, TypeF<TypeG…>>>
Rust Rover is terrible, they made it free and I still dont use it, Zed is great for Rust.
And not cheap either if you want the "ultimate" editions.
They absolutely are the state of the art. At the same time, opening just three or four medium size projects brings the editor to it’s knees on my M3 Max.
I like having many projects open.
I like having many projects open.
Webstorm kept crashing and grinding to a halt on my codebase. Vscode and neovim didn't have that issue so that's what I use now.
The support for remote or in-docker development has been an issue, personally. Terminal editors and VSCode are much more “it just works” in this regard, especially when joining codebases that used docker to isolate all the dependencies to actually run tests/services for local dev.
I don't really care about evangelising anything, but this bit:
> 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.
> 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.
Neovims most popular plugin manager lazy.nvim supports this (and I'm sure most other too).
Am I the only one scratching my head about how Zed will eventually monetize their business to satisfy the investors behind their $12M investment?
Indeed, and that is why I will not use Zed. I don't need my editor being a VC led product.
Most of the negatives mentioned (fragility, bugs, plugins breaking often) are specific to neovim.
It's one of the reasons why I am and will always keep using vim instead of neovim.
Vim is a much more mature ecosystem, less chasing the newest "plugin du jour", my vimrc is stable, based on a few dozen plugins which are feature complete and rock solid stable.
Not sure what this fragility is. I’ve been using Neovim from the very first days, and it’s been stable throghout.
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?
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?
Same. Neovim and plugins I use have been remarkably stable from the start
I used Vim for around 15 years before switching to Neovim. I have no desire to go back.
In my experience Neovim is very reliable, even when building off `master`, which I did for a couple of years.
In my experience Neovim is very reliable, even when building off `master`, which I did for a couple of years.
Yeah, I was on the nightly release (via nix) for a while. Rock solid.
I was about to make a very similar comment. I won't say I'll never switch to neovim, for a lot depends on future vim/neovim development, and unexpected things happen.
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.
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.
You don't have to chase plugins with either Vim or Neovim you know? You can even use the same Vim plugins in Neovim if you wanted to.
It's true that Neovim leans more towards more changes and thus more risk of bugs, but claiming that Neovim is unstable is unfounded.
It's true that Neovim leans more towards more changes and thus more risk of bugs, but claiming that Neovim is unstable is unfounded.
Do you mind sharing that list of plugins you use? I have never used plugins with vim/neovim and only used them vanilla up to this point but interested in checking out the plugin ecosystem.
This is a copy paste from the relevant part of my vimrc. Keep in mind I mainly develop in python.
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'
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'
Echoing the other replies here that idk what breakages this refers to. I switched since I liked lua better than vimscript (after writing a ton of vimscript). I don't use many plugins; the few I use haven't broken. Only encountered a single (non-serious) nvim bug that wasn't also a vim bug in many years of use.
I use maybe 10 plugins. I update them whenever I update nvim which isn’t all that often. Rock solid.
neovim is what happens when the javascript kids decide to "improve" one of the best editors ever created. The entire Lua ecosystem standing on 50 unstable plugins that provide the entire kitchen sink, yet do not even have a 1.0 version is nightmarish.
Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are completely antithetical to the slim, minimal philosophy of vim.
At least the original vim is still around, and the js kids are allergic to parens so there's an alternative.
Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are completely antithetical to the slim, minimal philosophy of vim.
At least the original vim is still around, and the js kids are allergic to parens so there's an alternative.
What on earth are you talking about?
When I was looking for an editor that supported true color themes, neovim supported them, vim didn't. That decided what I was going to use. Stability is good, but if you need a feature that's not there - stability isn't helping.
>neovim is what happens when the javascript kids decide to "improve" one of the best editors ever created
I don't think that's accurate. Now, if OTOH you said "the Lua kids" then I'd probably agree.
I don't think that's accurate. Now, if OTOH you said "the Lua kids" then I'd probably agree.
There are no Lua kids, i.e newbie programmers that start their career from Lua. The neovim Lua kids were JS kids all along, and brought their philosophy of churn over.
I am not a JS dev, and still prefer nvim. If you’re careful with plugin choices, you can get nice QoL features and still be stable. I can’t think of a time when I’ve had nvim crash.
You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.
You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.
Neovim is perfectly usable without installing 50 plugins.
I explored Zed on macOS when it was posted here previously, and my impression was that it was a fast and fully-featured editor.
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.
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.
It was a great sales pitch until the Linux and Apple comparison.
I can't take seriously someone, who says that Apple's stuff runs smoother (unless we are talking about useless animations).
I can't take seriously someone, who says that Apple's stuff runs smoother (unless we are talking about useless animations).
My dealbreaker with Zed is that it takes away my autonomy and agency.
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...
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...
I tried Zed just yesterday and sadly my experience wasn’t “just works”. It just works if you haven’t used any of the Neovim configs/distributions. But for someone who already uses LazyVim, LunarVim..etc., it’s kind of meeting the expectations.
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.
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.
Is it named Dockerfile or Dockerfile.jinja?
It’s named Dockerfile. However, I suspect if it’s named jinja, the Docker parts won’t be syntax highlighted!?!?
In my experience, yes. But you can't really expect a syntax highlighter to support every combination of template language and file language, so this seems reasonable enough.
I understand the limitation. Especially in the context of having the entire syntax tree parsed and stored like Zed.
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 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.
Right but the curly brace is invalid syntax in a Dockerfile. It's valid IMO for the parser to bail when it encounters this.
I see what you're saying that other highlighters are continuing gracefully though.
I see what you're saying that other highlighters are continuing gracefully though.
There is one big issue with terminal editors that I keep running up against: single font size. One notable place where this is an issue is file listings, being able to have smaller proportional fonts makes a huge difference in usability.
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).
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).
Telescope feels so game-changing, and I've not found anything like it outside of Neovim and Emacs. Being able to fuzzy search a buffer or my project instantly makes navigation insanely fast.
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.
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.
I mean every single editor has fuzzy file finding these days.
Yeah, it's definitely an issue I'd like to see tackled better. Neovim is already fully working under a client-server architecture, as far as I understand, i.e. the TUI is already "just" a client that connects to the main server process. There are some neovim GUIs such as Goneovim, Neovide, Fvim and even FireNvim (using neovim inside Firefox), but they mostly implement some windowing effects and whatnot, because I belive things are still somewhat tied to a cell based grid.
Despite all this, I daily drive neovide.
Does Zed support remote/containers development now? It was the major blocker for me when i tried it, so i had to retreat back to VSCode.
I’m not sure if programming is a social activity so their focus on collaboration is a little odd to me.
The remote editing features are in preview: https://zed.dev/docs/remote-development
I started using Zed in the last month and I had a feeling it would end up taking a lot of Neovim users. Neovim gets a lot of users who need better performance than VSCode, like me, but the config is such a pain and there was a gap in the market for a blazingly fast GUI editor which Zed looks like filling.
Supermaven still has some issues on Zed, but apart from that its been rock solid and ive fully switched from Neovim.
Supermaven still has some issues on Zed, but apart from that its been rock solid and ive fully switched from Neovim.
If you ever go back to Neovim, I’ve had a lot of fun with NVChad. I still had to configure a little bit for LSP but that’s part of the ethos - sane defaults and most stuff off by default for performance and to reduce clutter.
I have my Neovim setup the way I like it, the problem is every so often something breaks, and I have to dig back into the config and ive completely forgot how everything works. Theres just a complexity with neovim config that id rather not deal with, its a bad DX in this day and age.
I would love a modern Emacs with a better modern GUI similar to Zeds.
I'm still down to seriously consider Zed, but this is one of the most inorganic posts I have ever seen.
I love the smell of freshly cut astroturf
What do you mean? Give an example.
How so?
I tried out Zed and really like it, but its still lacking things like EditorConfig support, so project switching sucks. Has strong potential to replace vscode entirely if they don't get carried away with fancy features
I’m going to somehow misuse this discussion to ask for the readership help about something: I don’t understand the appeal of VSCode or more exactly I don’t understand the appeal of the text editor propped with plugins to be a semi-IDE so I guess that would also include Neovim with plugins.
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?
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?
Heh, I saw this thread just recently:
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.
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.
> VS Code is very noticeably faster than Eclipse
Even IntelliJ is noticably faster than Eclipse. This is a heavy indictment of Eclipse, not any other editors.
Even IntelliJ is noticably faster than Eclipse. This is a heavy indictment of Eclipse, not any other editors.
For me, VSCode is not a great editor. It feels cobbled together and often provides a worse development experience compared to language specific IDE
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.
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.
For remote development there is Fleet from JetBrains which is still in preview but mostly works (year ago it had a lot of issues). Nonetheless, it still needs a lot of improvements (rendering performance IME is poor, some functionality is missing in comparison to full-fledged IDEs like IntelliJ)
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?
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?
I kinda lost hope for fleet when it just started loading the intellij core to do all relevant stuff. I wanted that new editor so it would be faster, not so that I can have slightly different chrome.
> Why are you using VSCode over Vim for remote development?
Who's to say you have shell access to the remote instance?
Who's to say you have shell access to the remote instance?
I’ve used VSCode extensively because of its flexibility, remote extension, and (decent) speed. I enjoyed IntelliJ in the past, but I encountered countless performance issues on larger projects. This could be partially due to a subpar configuration, but over time I just gave up on IntelliJ and just used VSCode because it _just worked_.
As opposed to vim it has a gui, as opposed to eclipse and intellij its language agnostic, as opposed to you they obviously dont find it too slow to be a nice editor, having an inferior ui or miss any of the features.
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.
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.
Probably a mismatch between what I expect from an IDE and what VSCode offers then, I understand that. Every time I fire it I am always deeply disappointed by the lacklustre debugger and the lack of good refactoring tools.
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.
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.
Takes very little time to configure, new languages work with LSP in a few seconds, support for headless neovim, nice gui with good font rendering in macos, decent git integration, window management is good and can be customised to use vim bindings.
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.
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.
It's a fair question, my guess is that it's a great beginners IDE for multiple languages. You can quickly get up and running with all major languages, and it was one of the first products Microsoft made multiplatform and free. I'm neutral about it, it works fine for getting the job done. I'm a bit disappointed that it's ssh plugin craps out over 200MB of detritus on each remote machine it connects to. But the ability to edit remotely is a neat feature.
One answer may be that it’s not that slow for everyone. It could vary with the kind of computer you’re running it on, or what languages you’re using it for, or the size of the codebases.
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 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 love IntelliJ, but VS Code has much better support for frontend technologies and TypeScript.
Until you work on a front end code base that's meaningfully large
It's strange that you assumed I don't work on large front-end projects rather than either asking me or sharing your own experience.
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.
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.
The reason is simple: You write Java.
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.
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 have written Ocaml, Java, C, C++, Ada and Python professionally in my career. I either used an editor or an IDE. I had a plugin for eMacs when doing Ocaml but the experience was really subpar (that was before Merlin - yes, I’m that old).
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?
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?
> 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.
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.
> I’m sorry but having used both. VSCode is not faster
When you project your own experience over everyone else's it doesn't seem like you genuinely want to understand.
When you project your own experience over everyone else's it doesn't seem like you genuinely want to understand.
You know you are a text editor enthusiast when you spend 60% of your time fiddling with your config, 30% of your time writing about it, and 10% of your time working on something useful/interesting. Just use VS Code.
It's a matter of discipline. I've been migrating slowly to nvim, initially through motions in vscode and later by using both whenever I was lacking some features.
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.
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.
I can fall into this trap(?). It's probably a simple equation along the lines of the time saved needing exceed the time spent optimising (and all associated activities). The same thing can apply to productivity software, hardware, etc. There are probably diminishing returns. There's also the opportunity cost of using the same time practicing a skill that could lead to a greater efficiency benefit. I do know people get a kick out of tinkering with their tools, however, so it's not just efficiency.
I used Zed on Linux and liked it a lot... until I couldn't write a space in english layout (still worked on alternative layouts). Strange
I have a few default keybindings coming from Spacemacs/AstroNvim. In case anybody finds them useful, you can find them here: https://github.com/danieljaouen/dotfiles/blob/main/topics/ze...
>What normally required multiple plugins in Neovim is again ready out of the box with Zed, including feature like toggling Git Blame, viewing diffs, and gutter symbols showing the status of edited lines.
Pretty sure Gitsigns for neovim can do all mentioned (diffthis, blame line of file adnd obivously gutter symbols).
But if you need more you have Diffview and other plugins.
Pretty sure Gitsigns for neovim can do all mentioned (diffthis, blame line of file adnd obivously gutter symbols).
But if you need more you have Diffview and other plugins.
I just drop back to the terminal and use git itself (or install Fugitive). What I like about Vim/Emacs is how easy it is to tailor them to your usage patterns. Boilerplate generation, tools integration, and other programmable workflows can be quickly implemented.
There was a time when I was learning how to use Vim and I saw my boss use the mouse to do a simple copy and paste and there was kind of a disconnect between these two ways of using the computer.
From my experience a good mouse is better than a power tool like Vim, not for copy/paste, but just because it can reach the whole screen very fast and it works with all software although limited in text terminals.
Learning Vi(m) was still helpful because it's installed even on most docker images but that's not the "default" way of typing text. Most software accepts mouse double clicks or triple clicks and standard ways of using the keyboard (including use shift+ctrl+left and things like that), so that's how I like my IDE to work as well.
Multi-cursor is great and it's good that I don't miss it outside of the IDE because it wouldn't be useful outside of it anyway.
That because with Vim (and Emacs) the main tool for navigation is search. Even vim’s text objects are just search related to the cursor. That’s why you want quick file search, quick find in files, and powerful search and replace utilities. The issue with the mouse is that it adds friction between searching and editing. That’s where vim bindings and emacs chords come into play.
I'm using neovim with lazyvim. It's still not "easy" to keep up with e.g. I have plugins that interfere with other plugins, some crash. Part of that is that I have a bad habit of installing tons of plugins that "sound good" without learning them or where they fit exactly. I probably need to go one by one slowly.
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.
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.
Has anyone made the transition from VS Code to NeoVim or Zed and succeeded / recommend it?
Years ago I saw a colleague operate as an absolute beast using VS Code with vim bindings and it was impressive to watch.
But I've never watched anyone code in vim/emacs etc and felt it's a more effective editor than vs code.
Years ago I saw a colleague operate as an absolute beast using VS Code with vim bindings and it was impressive to watch.
But I've never watched anyone code in vim/emacs etc and felt it's a more effective editor than vs code.
I made the switch from notepad++/sublime (even atom did not exist at the time). The plus side was quick editing. Most of the time you spend on a code is rewriting it (excluding reading it) and vim binding made that a breeze. And even tools provided by IDEs can be great for code massaging, VIM is still king for raw editing. And if you know the shell, you don’t miss much from IDEs.
Nowadays, I’m exploring emacs because of how easy it is to build tools in it. Vim is great for working on text, but emacs is great for creating tools that work on text.
Nowadays, I’m exploring emacs because of how easy it is to build tools in it. Vim is great for working on text, but emacs is great for creating tools that work on text.
I tried leaving vim for Helix but turns out it's not curated at my employer's site so I'm back to using vim. Zed would be even worse considering it's a desktop app.
There is the option of using vscode but I'm one of those aliens who absolutely dislike that program.
There is the option of using vscode but I'm one of those aliens who absolutely dislike that program.
If your employer allows for you to build rust projects, Helix build and installation process from source is pretty straightforward, so that might be an option.
I’m with you on VSCode, I just can’t get into it. 20+ years of vim does mean there’s a lot of muscle memory I’m not willing to put aside, and last I checked (admittedly years ago), the vim plugin for VSCode was meh
Maybe you can give the neovim plugin for vscode a try. As a long time vim/neovim user who occasionally do some C# modding stuffs in vscode I find it one of the best "vim" mode plugin out there. The fact that it spawns a real neovim instance makes it working great with your existing neovim config, no need to learn how to add your custom other-than-default vim keymaps using some json config files, it just works, even for navigation plugin like leap.nvim (if my memory is correct).
Zed seems to be using its own vim emulation and config syntax is a huge caveat to me.
Zed seems to be using its own vim emulation and config syntax is a huge caveat to me.
Talking about text/code editor journey, currently I am using Pragtical, a fork of Lite XL. I have always wanted a GUI editor that is lightweight but easy enough to extend with plugin. And Pragtical and Lite XL almost checks all the box for me. There is still some missing features like code folding that has not been implemented, but it is not a killer feature for me.
I actually quite enjoy fiddling with it and I have been writing several plugins for Lite XL and Pragtical even though I have no experience on Lua before.
Lite XL's Matrix rooms (which is bridged with their Discord) is quite active and their member usually responds to any question asked.
Neovim has felt frustrating. I still sort of manage a Neovim configuration, but have been gradually moving to Zed as well. (Similar reasons overall.)
I think everyone has their own personal list of gripes and wants for a text editor. Here's some issues that I think many people will immediately be struck by:
- Zed does not yet support EditorConfig. https://github.com/zed-industries/zed/issues/8534
- Zed does not yet support auto-detecting indentation in the current file. https://github.com/zed-industries/zed/issues/4681
- Zed does not yet support configuring indentation in the current file. (edit: clarified wording) https://github.com/zed-industries/zed/issues/4867
- The core editing experience is still less polished than Monaco. Example: Selecting a block of spaces and striking "delete" may lead to an uneven number of characters being deleted. It seems to interact poorly with indentation.
- No settings UI (yet?).
As a Linux (and specifically NixOS) user, there's also a few other problems that I would love to have solved:
- Zed can't be configured to not auto-update, which can simply never work on immutable distros or e.g. inside of Flatpak. It just tries and fails, wasting bandwidth. https://github.com/zed-industries/zed/issues/9224
- Zed can't re-use all already-installed language servers yet, so some language servers can't be used on platforms where the auto-download feature can not work. https://github.com/zed-industries/zed/issues/4978
- Zed doesn't really integrate well with direnv. VSCode is in the same boat, but Vim is not. https://github.com/zed-industries/zed/issues/4977
Overall Zed has been very nice. It definitely feels like it's still pre 1.0, but it is a very strong pre 1.0 to me. I am a bit weary on the focus on collaboration and AI features so soon, but I do realize that people actually like these features, so hopefully it's not a sign that the core editing experience is going to be neglected.
I think everyone has their own personal list of gripes and wants for a text editor. Here's some issues that I think many people will immediately be struck by:
- Zed does not yet support EditorConfig. https://github.com/zed-industries/zed/issues/8534
- Zed does not yet support auto-detecting indentation in the current file. https://github.com/zed-industries/zed/issues/4681
- Zed does not yet support configuring indentation in the current file. (edit: clarified wording) https://github.com/zed-industries/zed/issues/4867
- The core editing experience is still less polished than Monaco. Example: Selecting a block of spaces and striking "delete" may lead to an uneven number of characters being deleted. It seems to interact poorly with indentation.
- No settings UI (yet?).
As a Linux (and specifically NixOS) user, there's also a few other problems that I would love to have solved:
- Zed can't be configured to not auto-update, which can simply never work on immutable distros or e.g. inside of Flatpak. It just tries and fails, wasting bandwidth. https://github.com/zed-industries/zed/issues/9224
- Zed can't re-use all already-installed language servers yet, so some language servers can't be used on platforms where the auto-download feature can not work. https://github.com/zed-industries/zed/issues/4978
- Zed doesn't really integrate well with direnv. VSCode is in the same boat, but Vim is not. https://github.com/zed-industries/zed/issues/4977
Overall Zed has been very nice. It definitely feels like it's still pre 1.0, but it is a very strong pre 1.0 to me. I am a bit weary on the focus on collaboration and AI features so soon, but I do realize that people actually like these features, so hopefully it's not a sign that the core editing experience is going to be neglected.
On indentation, most files are going to be autoformatted by the LSP, and there are tab_size settings in the languages section, needing specific file settings seems like an edge case.
As for collaboration and AI features, I have no use for them personally, but I think that's their avenue for future monetization, so I can't really complain that they are focussing on that when I get an amazing piece of software for free.
As for collaboration and AI features, I have no use for them personally, but I think that's their avenue for future monetization, so I can't really complain that they are focussing on that when I get an amazing piece of software for free.
> On indentation, most files are going to be autoformatted by the LSP, and there are tab_size settings in the languages section, needing specific file settings seems like an edge case.
Wow, absolutely not!
Just so we're clear, when I say "per-file" settings, I don't mean in the configuration. I mean at runtime overriding the indentation settings for an open file.
This is needed for many, many cases that I definitely don't consider edge cases.
- Configuration files: Loose configuration files might be in a bespoke format with no language server to begin with. JSON and YAML files can have pretty much any indentation style, and in many cases when editing configuration files there will be no "project-specific" configuration files to read from. I use my editor of choice to edit configuration files in various places including just in my home directory.
- You are not necessarily allowed to fully reformat files in a given project, even if the project has inconsistently-formatted files. Some LSPs are cooperative with this and won't change the indentation, since not all languages have a canonical format. Auto-detection is very important here.
- Even when an LSP is being used, that doesn't mean Zed is synced up with it. The Nix LSP will use whatever nixfmt binary you are using. I'm using nixfmt-rfc-style, which uses 2-space indentation, but the default in Zed seems to be 4-space indentation for Nix files, which means that without configuration it will be out-of-sync. (Generally this would be better to just configure globally but I'm just trying to say that having an LSP in and of itself doing formatting is not a panacea.)
In almost any editor I can think of, from Vim, to Visual Studio Code, to IntelliJ, to Notepad++, to kwrite, to gedit... I can at least override the indentation style if it is wrong for some reason. In Neovim I use vim-sleuth, and my indentation settings in Vim are very rarely incorrect no matter what file I'm editing where.
Modern text editors can and should do better than this, and almost always do; being able to change the current indentation settings is something most editors support before supporting most other basic functions. It's not a weird edge case, it's just flat-out a missing basic feature.
Wow, absolutely not!
Just so we're clear, when I say "per-file" settings, I don't mean in the configuration. I mean at runtime overriding the indentation settings for an open file.
This is needed for many, many cases that I definitely don't consider edge cases.
- Configuration files: Loose configuration files might be in a bespoke format with no language server to begin with. JSON and YAML files can have pretty much any indentation style, and in many cases when editing configuration files there will be no "project-specific" configuration files to read from. I use my editor of choice to edit configuration files in various places including just in my home directory.
- You are not necessarily allowed to fully reformat files in a given project, even if the project has inconsistently-formatted files. Some LSPs are cooperative with this and won't change the indentation, since not all languages have a canonical format. Auto-detection is very important here.
- Even when an LSP is being used, that doesn't mean Zed is synced up with it. The Nix LSP will use whatever nixfmt binary you are using. I'm using nixfmt-rfc-style, which uses 2-space indentation, but the default in Zed seems to be 4-space indentation for Nix files, which means that without configuration it will be out-of-sync. (Generally this would be better to just configure globally but I'm just trying to say that having an LSP in and of itself doing formatting is not a panacea.)
In almost any editor I can think of, from Vim, to Visual Studio Code, to IntelliJ, to Notepad++, to kwrite, to gedit... I can at least override the indentation style if it is wrong for some reason. In Neovim I use vim-sleuth, and my indentation settings in Vim are very rarely incorrect no matter what file I'm editing where.
Modern text editors can and should do better than this, and almost always do; being able to change the current indentation settings is something most editors support before supporting most other basic functions. It's not a weird edge case, it's just flat-out a missing basic feature.
They probably should have the option to change the tab size on an open file, but my point is, why wouldn't you have autoformatting on for YAML and JSON? You have a preference for indent size, and you want the same for every file, barring an edge case.
"languages": { "JSON": { "tab_size": 4 }, "JSONC": { "tab_size": 4 }, "YAML": { "tab_size": 4 } }
Edit: Yeah I see your point when you are not in control of the project and have to stick to someone elses style, I guess that only seems like an edge case to me, but could be normal for other people. In that case you would want a convenient way to override your formatting settings, like an auto detect indent button that only applies to the current open file.
"languages": { "JSON": { "tab_size": 4 }, "JSONC": { "tab_size": 4 }, "YAML": { "tab_size": 4 } }
Edit: Yeah I see your point when you are not in control of the project and have to stick to someone elses style, I guess that only seems like an edge case to me, but could be normal for other people. In that case you would want a convenient way to override your formatting settings, like an auto detect indent button that only applies to the current open file.
To me it basically seems backwards. Of course I am not arguing against having a robust configuration for setting indentation settings, it's usually the ideal way to handle this sort of thing. However, it's ultimately still just a convenience feature; all you really need is the ability to set the indentation settings for the current buffer.
As far as editors that have automatic indentation features, Zed is definitely the first one I can think of where it had configuration for indentation settings per project/per language, but no ability to change it for the current buffer.
I'm sure in due time, it will probably gain most of these features as more people jump in and run into these problems.
As far as editors that have automatic indentation features, Zed is definitely the first one I can think of where it had configuration for indentation settings per project/per language, but no ability to change it for the current buffer.
I'm sure in due time, it will probably gain most of these features as more people jump in and run into these problems.
So I read this not expecting to like Zed that much.
I remember initially it was only for Mac, which... is just not good enough for me.
Anyhow, I reinstalled it and it is really good. Github, Copilot were integrated in no time... I really appreciate that and it is very clean and easy to use.
I remember initially it was only for Mac, which... is just not good enough for me.
Anyhow, I reinstalled it and it is really good. Github, Copilot were integrated in no time... I really appreciate that and it is very clean and easy to use.
> Whenever I need to edit a configuration file for an app or just edit something really quickly while I’m already navigating in a terminal, nothing beats the convenience of whipping out Neovim. Opening Zed for every single file like that would get exhausting, but for longer term sessions or projects it’s perfect.
Which part exactly would exhaust you? These editors are fast to close/open even is there not already running (also you could just leave it open h, and you get the benefit of not blocking the current terminal session, so that's the convenience that beats neovim. Another one is that you can have editor's window size independent of the terminal size
Which part exactly would exhaust you? These editors are fast to close/open even is there not already running (also you could just leave it open h, and you get the benefit of not blocking the current terminal session, so that's the convenience that beats neovim. Another one is that you can have editor's window size independent of the terminal size
I have used multiple stuff since 1986, if it isn't an IDE like tool, I won't bother.
These kind of editors switching is like repairing that old covertible triumph from 1950 on the garage, interesting for some, not really something I care about.
These kind of editors switching is like repairing that old covertible triumph from 1950 on the garage, interesting for some, not really something I care about.
Has Zed started hiding the mouse cursor when typing? If not, I'll wait.
I have started using Zed as the secondary editor, after VSCode, since they added the repl feature, which is based on Jupyter. It's not that it's a killer feature but that and AI, out of the box, and the cleaner UI attracted me.
That said I actually been using Cursor more in my testing of AI code because they just have better AI (with regard to how they add things into the context, I use both with sonnet). Also the UI integration is more comprehensive.
That said I actually been using Cursor more in my testing of AI code because they just have better AI (with regard to how they add things into the context, I use both with sonnet). Also the UI integration is more comprehensive.
I can't escape Sublime Text's grip. The editor is incredibly smooth and gets out of the way like no other. (Tried a bunch of them). However, lately I started opening Zed on occasion just to ask ChatGPT to make a non-trivial edit on a bunch of code. The way Zed does inline AI assist is unmatched. That's why I can't wait for Sublime to gain this functionality, so that I can calm down and stay with it.
Same, ST is the best
But they really need to speed up the pace of their updates and offer plugin API that interacts with the UI
But they really need to speed up the pace of their updates and offer plugin API that interacts with the UI
For a GUI editor, Zed is nice, but for me, the killer feature of vim is that it runs inside a terminal emulator. Being able to SSH-in, or even dial-up, and work directly on a remote machine is huge. Some GUI editors have SSHFS integrations that make it easier to edit remote files, but I've found them to all be rather unreliable, and unavoidably so--given the inherently unreliable nature of networks.
I like Zed too and use it on a daily basis. I've always wanted to take the opposite journey where I leave Zed/Sublime for Vim. While I have always to become a Vim expert, I never put in the time. There just hasn't been a situation in my career where I wish I could type faster than my thoughts. But maybe I'm just a scrub in this field.
as a long time vimmer, the advantage isn't anything to do with editing speed, people can edit quickly in most any editor these days. It's more about having this editing "language" that allows you to be pretty expressive about the edits you want to do in a precise and concise way. This Verb+noun language takes a while to learn, but when you get reasonably fluent in it, other ways of editing just feel like more work. To me, this feels like it frees up my thought process. If you imagine refactoring tools, they let you make changes that you could do at a lower level, but they just make life easy. Vims language is like a mini editing refactoring tool that combos in a lot of different ways that just feels easy once you get the hang of it.
It is great to see new editors gaining traction after VSCode took most of the market.
i wish i could speak in length about how the ide i use helps me be the "10x" dev i am clearly not.
i would say this as a mid-level dev in a team spread across geographies, however: when using a workflow that should work for all, it is more important to have a tool that works for all rather than the "best" one.
unfortunately, neither (neo)vim nor zed seem to be in a place where an entire team could easily adopt to its workflow. the latter probably needs a while to marinate and become suitable for most.
i would say this as a mid-level dev in a team spread across geographies, however: when using a workflow that should work for all, it is more important to have a tool that works for all rather than the "best" one.
unfortunately, neither (neo)vim nor zed seem to be in a place where an entire team could easily adopt to its workflow. the latter probably needs a while to marinate and become suitable for most.
Just another +1 that if you’re going to give vscode a fair shot, it’s much better to go with vscode-neovim than the standard vim extension. You can even map most of your config right over.
E.g. (mine) https://github.com/tom-pollak/dotfiles/tree/master/nvim
E.g. (mine) https://github.com/tom-pollak/dotfiles/tree/master/nvim
I've found Zed's vim mode to be great for learning vim without having to give up all of my muscle memory built up from using vscode for so long.
"Just works" is fine... Until it does not, and you have a hard time finding the issue. I prefer more control over my editor.
I personally use Vim because it lets me use the keyboard for everything. In Zed there are still lots of places I have to use the mouse.
I’m currently using VS Code with the Neovim extension. Has anyone migrated to Zed from Code? Curious what your experience has been.
I've tried it a few times, and each time there's been something missing that was too irritating to live without - stuff like git integration, or extensions that I use a lot. It's nice, but I don't really notice the speed much once the application is open and running, and so I just ended up back at vscode every time.
I've used VS Code for my Rust development for several years, and I tried out Zed for a couple weeks earlier in the summer. The integration with `rust-analyzer` wasn't super smooth though, so I've switched back for now but would consider trying it again when it's more mature.
opens newspaper i should try using a vim plugin at some point
A good article, but you really can't see the screenshots at all.
Seems like the guy’s website got hugged?
When I hear about zed, I have to think for a bit to realize it is not zed.exe that came with Zortech c v1.0 for MS-DOS :)
jEdit is the most underrated editor ever
I die inside whenever I use `\<` and `\>` for word boundary regex. Neovim has no plans to change this either. I'll likely switch eventually so I don't have to know two flavors of regex. One is hard enough.
Only two?! *cry in posix BRE, posix ERE, PCRE, JS regexp, .NET regexp, emacs regexp*
...you just made me realize I know (some of) the differences between JS and .NET regexp, in addition to vim and PCRE.
Profanity.
Profanity.
I just add `\v` (very magic) to make it interpret regex more strictly. I’ve just tested it and you don’t need to escape these anymore to match word boundaries.
Use `\v` then `<` and `>`, and you can make it default.
I gather that in really old regex syntax the word boundary syntax used to be like this:
[[:<:]]foo[[:>:]]
> Every now and then I would update a plugin [...]
Why would you do that? I keep my plugins pinned at whatever old version I happened to use first...
Why would you do that? I keep my plugins pinned at whatever old version I happened to use first...
Honestly, I don’t understand when someone says VSCode is slow because it’s built on Electron. Are they talking about the 3 extra seconds on cold start? Is that really something to scoff at considering all its benefits??
On my laptop there is a noticeable keystroke delay compared to other editors.
I've paralyzed VSCode by opening a 20MB file with test data.
Not the tab, the whole workspace. Force quit and everything.
VSCode has its upsides but it's a dog.
Not the tab, the whole workspace. Force quit and everything.
VSCode has its upsides but it's a dog.
For what it does, it’s slow. I used Jetbrains IDEs and I understand the slowness because of all the linting and indexing. But I bear with it because they are tailored to the language that they support and provide you with great utilities. VSCode tries to be the kitchen sink and it’s not great at either. And it’s not just code editing, every interaction with the interface feels slow. If I have 12 cores and 32 GB of ram, slowness for the same thing I was doing on codeblocks with a P4 and 1 GB of ram is the last thing I would accept.
Depends how often you’re opening / closing it, I suppose. I work in an nvim + tmux environment, and am frequently opening and closing single files across disparate directories, so it does matter to me. I can spawn a new pane (or split existing), open nvim, and be editing before VSC has finished launching.
You can open files from disparate directories within the same VSCode instance though.. you don't need to launch a new instance for each one.
Zed’s dead, baby. Zed’s dead.
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.