Neovim 0.8 Released(github.com)
github.com
Neovim 0.8 Released
https://github.com/neovim/neovim/releases/tag/v0.8.0
229 comments
> If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors like https://helix-editor.com/, or new native GUI editors like https://zed.dev/ ?
VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks. Also for my personal use, everything that's not vim suffers from being not vim; it would cost me effort to switch for no clear benefit, and I'd still need to retrofit the same control scheme into whatever it was because the muscle memory is too strong, at which point I might as well just use actual neo/vim.
> which were built to be used as rich development environments instead of extensible text editors
> spent months tweaking Neovim/Emacs configs
I think part of the difference might be of usecase; if you want an IDE, use an IDE. If you needed to spend that much time bending the tool to what you want, maybe it wasn't a good tool to use. When I open vim, it's because I want a text editor, and it provides a text editor.
VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks. Also for my personal use, everything that's not vim suffers from being not vim; it would cost me effort to switch for no clear benefit, and I'd still need to retrofit the same control scheme into whatever it was because the muscle memory is too strong, at which point I might as well just use actual neo/vim.
> which were built to be used as rich development environments instead of extensible text editors
> spent months tweaking Neovim/Emacs configs
I think part of the difference might be of usecase; if you want an IDE, use an IDE. If you needed to spend that much time bending the tool to what you want, maybe it wasn't a good tool to use. When I open vim, it's because I want a text editor, and it provides a text editor.
> VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks.
Perspectives like these (and others in the thread) remind me that there exists a separate cohort of engineers from people like myself which have absolutely polar opposite views. I respect your opinions, though I couldn't disagree more with them! :)
Well, except the bit about VSCode having "spyware". That's not true, and it weakens your point. It does have telemetry - I suspect that's what you mean, and you should just call it that instead.
Perspectives like these (and others in the thread) remind me that there exists a separate cohort of engineers from people like myself which have absolutely polar opposite views. I respect your opinions, though I couldn't disagree more with them! :)
Well, except the bit about VSCode having "spyware". That's not true, and it weakens your point. It does have telemetry - I suspect that's what you mean, and you should just call it that instead.
No. Microsoft's general reputation for spying on its users renders "spyware" a reasonable shorthand for what it either does now, or perhaps is reasonably likely to do at some time in the future.
I would fall back to the softer "telemetry" ONLY IF they were to provide some sort of genuinely reliable affirmation that it's not spying, which I don't think they could do today absent legal or other generally obvious incentive.
I would fall back to the softer "telemetry" ONLY IF they were to provide some sort of genuinely reliable affirmation that it's not spying, which I don't think they could do today absent legal or other generally obvious incentive.
I mean, you can say whatever you want - you only diminish your own argument by doing so. It's like the boy who cried wolf - if you keep shouting "spyware" with no true evidence of spyware, then by the time that "spyware" actually is happening, no one is going to care.
> what it either does now
Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.
> perhaps is reasonably likely to do at some time in the future
An imagined hypothetical does not help your argument.
> what it either does now
Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.
> perhaps is reasonably likely to do at some time in the future
An imagined hypothetical does not help your argument.
> Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.
Well, yes, of course Google would say that. If you ask DuckDuckGo to define spyware, it offers these:
> Software that secretly gathers information about a person or organization.
> programs that surreptitiously monitor and report the actions of a computer user.
Which of course is exactly what VSC does.
Well, yes, of course Google would say that. If you ask DuckDuckGo to define spyware, it offers these:
> Software that secretly gathers information about a person or organization.
> programs that surreptitiously monitor and report the actions of a computer user.
Which of course is exactly what VSC does.
That's wrong. They key element of "spyware" is that it monitors and reports outside of it's own realm, and cause damage with the data. Like a keylogger logs keys even it's not the active program. What VSCode does is only monitoring user action within VSCode for technicality. Until you can provide evidence otherwise, calling it "spyware" is act of defamation.
Also, if software with telemetry is spyware, there is no mainstream browser clean. Feel free to use forks like Tor Browser or VSCodium if you like, but expanding the scope of spyware unreasonably only gonna cause confusion to average people.
Also, if software with telemetry is spyware, there is no mainstream browser clean. Feel free to use forks like Tor Browser or VSCodium if you like, but expanding the scope of spyware unreasonably only gonna cause confusion to average people.
It's not "expanding the scope," it's clarifying (or developing) a definition.
And if it causes confusion -- good. There should be more public confusion on this topic, especially in the realm of "Why does this free program need to know all of this stuff about what I'm doing?"
It's not that answer is "no gathering information ever," it's "providers of a program ought to be compelled to fully and clearly disclose to all what information it is grabbing and what it is doing with it."
And that's emphatically not where we live today.
And if it causes confusion -- good. There should be more public confusion on this topic, especially in the realm of "Why does this free program need to know all of this stuff about what I'm doing?"
It's not that answer is "no gathering information ever," it's "providers of a program ought to be compelled to fully and clearly disclose to all what information it is grabbing and what it is doing with it."
And that's emphatically not where we live today.
[deleted]
Even the FTC struggles to define spyware. But I think you’re right that a disagreement on the definition is at the heart of all of this. I wouldn’t be so overconfident in asserting that spyware is defined in your particular way here, though. There isn’t exactly a consensus! VSCode is certainly not to be lumped in with password stealing keyloggers, but because they continue collecting telemetry data even after you explicitly disable it, VSCode does fall under the “collecting data without a user’s knowledge” category of spyware.
I'm very comfortable calling ALL OF IT spyware until something like the GDPR cookie thing exists for it. (or they voluntarily make such a statement BEFORE you use it)
Calling spyware an "imagined hypothetical" re Microsoft is like calling "too hot coffee" an "imagined hypothetical" for McDonalds.
They've already done it a bunch. Are you naive enough to 100% believe their pinky swears?
They've already done it a bunch. Are you naive enough to 100% believe their pinky swears?
Sure, let’s have any example of this by any reputable news source then.
literally the first hit for "microsoft spyware" is the following:
https://www.gnu.org/proprietary/malware-microsoft.en.html
gnu.org not reputable? Hey, no worries, it's an ENORMOUS ANNOTATED list. Have fun.
https://www.gnu.org/proprietary/malware-microsoft.en.html
gnu.org not reputable? Hey, no worries, it's an ENORMOUS ANNOTATED list. Have fun.
We're not talking about MS the company, we're talking about VSCode, the product, as OP's claim was that it's apparently well-known that VSCode is spyware. Ctrl-F "VSCode", "Visual Studio" both come up with 0 results.
I have a tangental concern, which is that all things microsoft these days seem to be evolving towards an advertising platform or a subscription. The way they keep adding integrations into their other stuff is understandable, and doubtless convenient for many people, but I can't help but think that someday after they are deeply embedded in the workflows of large swaths of the development community a message will appear in your editor suggesting an upgrade to the pro version of some tool or plugin and the freemium experience will have arrived.
Lots of big tech companies (including mine) let their devs run VSCode on company machines. If there was a concern about spyware, I feel like all of those security teams across the industry wouldn't have signed off on this, especially with billions of dollars of IP at stake.
Like log4j!
I think there's a bit of a difference between a bug that went undiscovered for years and vetting third-party software to see if its telemetry compromises your employees or IP.
I mean, sure, if you want to avoid log4j from happening, you can write all of your software from the ground up in-house with no third party dependencies (or audit every line of code for every third-party program you do use), but I don't see how that's relevant to a discussion about whether VSCode is compromised to a degree that other editors aren't.
I mean, sure, if you want to avoid log4j from happening, you can write all of your software from the ground up in-house with no third party dependencies (or audit every line of code for every third-party program you do use), but I don't see how that's relevant to a discussion about whether VSCode is compromised to a degree that other editors aren't.
The point was that people thought "Oh surely log4j was vetted by the big companies that depend on it - I mean it must be OK if AcmeCorp uses it!". (or openssl, or sendmail, or ...). That's not too different from "Oh look at all these big tech companies using it, they must have vetted the telemetry".
Maybe a little extra caution is warranted.
Maybe a little extra caution is warranted.
Ah telemetry - you mean software that sends back information about what I'm doing to some 3rd party? Unlike spyware which is software that sends back information about what I'm doing to some third party.
Totally different, got it.
Totally different, got it.
I said this to someone else, but spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.
Why does Google get to decide that software has to "hide on your device" and that it has to steal banking information or passwords to meet the definition of spyware?
I don't want MS to monitor me. Anything that enables them to track me better is sensitive because I don't want to be monitored.
No one stops you from using VSCodium. But associating a software with spyware (a black/white action) should not but tied to how much telemetry (a spectrum) they collect. It's about what type of data they collect and what they do with the data. If they deliberately use that data to cause any damage (black/white), you can call it spyware. But if they only use that to improve their software, no, you shouldn't.
There have been reports that the "telemetry" is sent after a user takes the actions to disable it.
That means that a user has information about them reported in a way that is:
1. against their will
2. without their knowledge
That is spying. The software that does it is spyware.
Whether or not they intend to use it for anything other than improving the software - if they secretly take data from me without my consent, it's spying.
Whether or not you think it's OK for them to take data, if they do so without my consent, it's spying.
Whether or not you really like VSCode, if they secretly take data without my consent it's spying.
Software that spies is spyware. It's that simple.
Trying to haggle in the margins of one definition of a vague term is not a very strong argument to convince me otherwise.
Also: about the first part of your comment - I stop me from using VSCodium. I'm not interested.
That means that a user has information about them reported in a way that is:
1. against their will
2. without their knowledge
That is spying. The software that does it is spyware.
Whether or not they intend to use it for anything other than improving the software - if they secretly take data from me without my consent, it's spying.
Whether or not you think it's OK for them to take data, if they do so without my consent, it's spying.
Whether or not you really like VSCode, if they secretly take data without my consent it's spying.
Software that spies is spyware. It's that simple.
Trying to haggle in the margins of one definition of a vague term is not a very strong argument to convince me otherwise.
Also: about the first part of your comment - I stop me from using VSCodium. I'm not interested.
It secretly collects data (spies), so it is spyware. Which part do you not get?
> and you should just call it that instead.
And then turn it off using the built-in setting:
https://code.visualstudio.com/docs/getstarted/telemetry#_dis...
And then turn it off using the built-in setting:
https://code.visualstudio.com/docs/getstarted/telemetry#_dis...
- https://www.roboleary.net/tools/2022/04/20/vscode-telemetry.html
- "It looks like you cannot shut telemetry off 100%. These settings will
opt you of most data sharing scenarios; but not all data sharing
scenarios."
- Apparently even VSCodium can't kill it all
- https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetryYou could also, if you wish, audit the telemetry events and determine if it's worth turning off - or decide that it's okay with you that they're using that data to improve their free product.
https://code.visualstudio.com/docs/getstarted/telemetry#_vie...
https://code.visualstudio.com/docs/getstarted/telemetry#_gdp...
https://code.visualstudio.com/docs/getstarted/telemetry#_vie...
https://code.visualstudio.com/docs/getstarted/telemetry#_gdp...
I could also just decide that it's okay to use a free editor that doesn't report on me in the first place. I don't need to audit exactly what information vim sends off and evaluate whether it's too much, because "none" is really easy to decide on.
Searching for excuses to let the company's product spy on you sounds like a huge waste of time.
Vscodium is pretty great though.
I use VSCode since switching away from Neo/Vim because things just work. I don't have to install a bunch of plugins like I used to where I don't know what works and what doesn't work with each other. For example, for Rust, I go to VSCode extensions page, click install on rust-analyzer, and that's it. I don't have to set up an LSP, syntax highlighting, etc which are each their own plugin on Vim.
That's funny, I just switched from VSC to NeoVim because things just work. The C++ LSP bindings for Vim were easier to set up, faster, and more reliable than my setup in VSC. Though I imagine these things vary greatly, since C++ and C++ tooling is enormously complex and varies from codebase to codebase.
I just want to express why I sometimes prefer things that don't "just work". I love VSCode. I use (neo)vim just because I am used to them (started using them before VSCode was around).
Firstly, not "just work" means there will be no features to suddenly appear and "help" me. When I start to use a new IDE I never know what inserting "{" does: Will a "}" also appear? Will it start a new line? Will it cause indentation to change? Will it insert a whole snippet? How do I just insert a "{"? An IDE usually comes with lots of "helper" features like this, and questions like these add up. The result is that I never know what happens when I press a key and get agitated when the result isn't what I expect. If I set up everything myself this doesn't happen. (neo)vim is pretty bad in this sense actually. The default formatoptions and filetype indent plugins are pretty annoying, and the "J" normal mode command has behaviors that surprise users and cannot be turned off (you can remap it for sure), but by the time I met VSCode I got familiar enough with them already... I recall VSCode's default was pretty clean. IDEs are absolutely the worst.
Not "just work" also means that I know how to change something if it steps into my way, since I set up everything myself. If I have to edit a file with special formatting rules that I need to follow, I know where to change auto formatting rules. If I have to read some generated code or code from dependency libraries, I know where to turn off warnings from linting. Since rust-analyzer is set up by myself, if one day I find that its version or config is not compatible with this new project I am starting to work on, I know immediately how to change it. If my whole setting up effort is "clicking a button", it becomes harder for me to find where the change needs to be made. Such things are not just "if"s actually, but happen pretty often from my experience, often enough to make me think it's better to set up everything myself than to figure things out each time.
Firstly, not "just work" means there will be no features to suddenly appear and "help" me. When I start to use a new IDE I never know what inserting "{" does: Will a "}" also appear? Will it start a new line? Will it cause indentation to change? Will it insert a whole snippet? How do I just insert a "{"? An IDE usually comes with lots of "helper" features like this, and questions like these add up. The result is that I never know what happens when I press a key and get agitated when the result isn't what I expect. If I set up everything myself this doesn't happen. (neo)vim is pretty bad in this sense actually. The default formatoptions and filetype indent plugins are pretty annoying, and the "J" normal mode command has behaviors that surprise users and cannot be turned off (you can remap it for sure), but by the time I met VSCode I got familiar enough with them already... I recall VSCode's default was pretty clean. IDEs are absolutely the worst.
Not "just work" also means that I know how to change something if it steps into my way, since I set up everything myself. If I have to edit a file with special formatting rules that I need to follow, I know where to change auto formatting rules. If I have to read some generated code or code from dependency libraries, I know where to turn off warnings from linting. Since rust-analyzer is set up by myself, if one day I find that its version or config is not compatible with this new project I am starting to work on, I know immediately how to change it. If my whole setting up effort is "clicking a button", it becomes harder for me to find where the change needs to be made. Such things are not just "if"s actually, but happen pretty often from my experience, often enough to make me think it's better to set up everything myself than to figure things out each time.
on linux, kde/kate is pretty good... I switched back to full tmux+vim lately to get even better with vim, but I find that kate is the perfect mix between an ide and a terminal based editor. makes me think of notepad++ with a few extra goodies (files on the left, terminal below etc...)
Last time I tested Kate's vim mode the g letter did not work in insert mode.
Kate looks great but seems even more overwhelming to configure than Vim
Hmmm, did some of the mappings change with this release? Now hitting CTRL-B (I do that a lot in NERDTree) gives me the "E5248: Invalid character in group name" error.
If VSCode "sucks", then isn't it weird that the vast majority of people seem to love and even prefer using software that "sucks", including GP?
I'm not sure how you'd know that; since vim, emacs, and other more traditional options don't include telemetry we don't know how many people use what editors. In any event, Windows remains the most-used (desktop) OS, so I've long since acclimated to people living with the suckage.
There's some data here that can help give a clue: https://survey.stackoverflow.co/2022/#most-popular-technolog.... It does look like vscode is the most used by a very large margin.
Scrolling up, the same sample put NPM use at 65.17%, so I feel pretty comfortable calling it sample bias.
The data is no doubt biased, but given just how far ahead vscode is, it would need to be a very heavy bias to see vim/nvim come out ahead among all developers (however we define that). It gives us some information, but I agree doesn't tell us what the proportion is among all developers.
Popularity is not a great metric of goodness, unless we want to come to terms with the fact that Limp Bizkit records are around 3x as good as VSCode (and that's despite the fact that they aren't even charging people for VSCode!)
In addition to programming, part of my job involves doing linux admin stuff, when I login to a server I expect vim to be there, and if not it takes a few seconds to install it.
I usually try something on my local machine and switch to the server and do this back and forth and sometimes the other way around, I have a test server where I test something before trying it on my local machine. Having the same text editor on all of these environments mean I don't have to context switch much, also I have my own custom config which I have been improving over the years and the fact I have multiple vim instances running right now and they are all consuming less than 120MB memory and the fact it responds really really fast is a really nice addition.
When I first started using vim I remember I asked one of my friends the following, "what the hell is wrong with people, why do they love using this god awful garbage" I remember my friend asking me to keep trying for a little while longer. Thank heavens I took his advice, I can't really remember when it happened but one day it just made sense.
Then I saw a neovim config file, and how good it looked with lua scripting, changed my old vim config in to a neovim one, and now I use neovim.
(plus I still have trust issues with a certain multi billion dollar company)
I usually try something on my local machine and switch to the server and do this back and forth and sometimes the other way around, I have a test server where I test something before trying it on my local machine. Having the same text editor on all of these environments mean I don't have to context switch much, also I have my own custom config which I have been improving over the years and the fact I have multiple vim instances running right now and they are all consuming less than 120MB memory and the fact it responds really really fast is a really nice addition.
When I first started using vim I remember I asked one of my friends the following, "what the hell is wrong with people, why do they love using this god awful garbage" I remember my friend asking me to keep trying for a little while longer. Thank heavens I took his advice, I can't really remember when it happened but one day it just made sense.
Then I saw a neovim config file, and how good it looked with lua scripting, changed my old vim config in to a neovim one, and now I use neovim.
(plus I still have trust issues with a certain multi billion dollar company)
Because when I started using Vim, VSCode and Helix weren't around. And now I know Vim (Neovim) very well and it does everything I need - I'm productive with it and it's lightweight.
I don't want a full IDE/graphical editor. Eclipse is a mess, I'd use a JetBrains product first, but now we have VSCode as an alternative. Atom was hot for a while but has lost popularity.
Of the (linux) terminal text editors, the choices were mostly:
* Emacs * Vim/Neovim * Nano
And I prefer Vim over Emacs, I really like the modal experience.
I don't spend a huge amount of time tweaking things, I use Neovim mostly stock with some useful plugins for convenient shortcuts. Though I admit that getting the new treesitter/language server integrations working was annoying, compared to the original regex-based syntax highlighting.
My goal is not to recreate an IDE experience in Neovim, I just want an efficient text editor that is syntax-aware.
If I wanted an IDE then I'd use an actual IDE.
I don't want a full IDE/graphical editor. Eclipse is a mess, I'd use a JetBrains product first, but now we have VSCode as an alternative. Atom was hot for a while but has lost popularity.
Of the (linux) terminal text editors, the choices were mostly:
* Emacs * Vim/Neovim * Nano
And I prefer Vim over Emacs, I really like the modal experience.
I don't spend a huge amount of time tweaking things, I use Neovim mostly stock with some useful plugins for convenient shortcuts. Though I admit that getting the new treesitter/language server integrations working was annoying, compared to the original regex-based syntax highlighting.
My goal is not to recreate an IDE experience in Neovim, I just want an efficient text editor that is syntax-aware.
If I wanted an IDE then I'd use an actual IDE.
Why? Here are some reasons in no particular order!
* +20 years of muscle memory
* Total customizability, when you get good at configuring and writing small scripts it feels like you can do anything. VSC feels like it's all about plugins
* On the fly remaps. E.g writing latex and quickly add insert mode remaps for things you are currently writing about ":imap CO2 $CO_{2}" for a prettier version of CO2 as you type. Playing around with Zig? With ":map ,t :w<CR>:!zig test %<CR>" you can type ,t and it saves and tests the current file.
* Write simple scheme files for pattern matching with Treesitter to conceal unnecessary clutter in some programming languages
* Snippets, other editors have this as well but with Luasnip I program every aspect of how it works exactly as I want it
* Even with a bunch of plugins it starts in less than 100ms
* +20 years of muscle memory
* Total customizability, when you get good at configuring and writing small scripts it feels like you can do anything. VSC feels like it's all about plugins
* On the fly remaps. E.g writing latex and quickly add insert mode remaps for things you are currently writing about ":imap CO2 $CO_{2}" for a prettier version of CO2 as you type. Playing around with Zig? With ":map ,t :w<CR>:!zig test %<CR>" you can type ,t and it saves and tests the current file.
* Write simple scheme files for pattern matching with Treesitter to conceal unnecessary clutter in some programming languages
* Snippets, other editors have this as well but with Luasnip I program every aspect of how it works exactly as I want it
* Even with a bunch of plugins it starts in less than 100ms
I was not familiar with Helix or Zed, so I took a look at the links.
Both webpages prominently state that the editors are written in Rust. This reduces my interest in both projects.
As a user, I do not care what language my editor is implemented in. Maybe I want a fast editor, or maybe I want a feature-rich editor. The closest I would come to caring about this is if I want an extensible editor - can I extend these editors using Rust?
Lacking any explanation as to why I should care that the editor is written in Rust, the conclusion I draw is that the creators of the editor were interested in an exercise in writing an editor in Rust - which I'm sure is a wonderful learning experience for the creators, but I don't see why that would make me interested in using the editor.
Both webpages prominently state that the editors are written in Rust. This reduces my interest in both projects.
As a user, I do not care what language my editor is implemented in. Maybe I want a fast editor, or maybe I want a feature-rich editor. The closest I would come to caring about this is if I want an extensible editor - can I extend these editors using Rust?
Lacking any explanation as to why I should care that the editor is written in Rust, the conclusion I draw is that the creators of the editor were interested in an exercise in writing an editor in Rust - which I'm sure is a wonderful learning experience for the creators, but I don't see why that would make me interested in using the editor.
I don't get along very well with the HN Rust Community (and I think I'm even less popular with them than they are with me), but fair is fair and the Rust folks have been absolutely revolutionizing the modern terminal experience.
Put differently, I take the opposite view: seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool. Something like 70% of the command-line nix packages in my home manager are written in Rust.
Put differently, I take the opposite view: seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool. Something like 70% of the command-line nix packages in my home manager are written in Rust.
> seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool.
I maintain clap, the most common CLI parser for Rust. When soliciting feedback on changing some of the `--help` formatting, a piece of a feedback I got from a couple of people was some of the distinctive look told the reader it was written in Rust and using clap and "that means a certain baseline of quality and behaviour".
I maintain clap, the most common CLI parser for Rust. When soliciting feedback on changing some of the `--help` formatting, a piece of a feedback I got from a couple of people was some of the distinctive look told the reader it was written in Rust and using clap and "that means a certain baseline of quality and behaviour".
For me the thing is if is written in rust it has more chances to get more contributors, besides all the rust benefits (fast, performant as if it were written in C, but without the worries of the memory issues).
Also just because I use rust, I could contribute, for C/C++ editors I will not be able, maybe I'll also give a chance if the editor were written in Go, but no other language, all the others are slow.
Also rust IMHO has a few apps (including commands) that are worth checking:
- Helix - Alacritty - Wezterm - Nushell - Zoxide - Starship
Then are others to replace grep, and other commands that I cannot remember from the top of my head.
Also just because I use rust, I could contribute, for C/C++ editors I will not be able, maybe I'll also give a chance if the editor were written in Go, but no other language, all the others are slow.
Also rust IMHO has a few apps (including commands) that are worth checking:
- Helix - Alacritty - Wezterm - Nushell - Zoxide - Starship
Then are others to replace grep, and other commands that I cannot remember from the top of my head.
> This reduces my interest in both projects.
That's funny, it's the opposite for me.
> As a user, I do not care what language my editor is implemented in.
I do care. I don't like using Electron apps, even if I have to grudgingly use them a la VSCode. If an app is in Electron or some other slow framework like a Python GUI, my interest immediately drops to zero. If it's in Rust or some other low level language, at least I know it'll be fast.
That's funny, it's the opposite for me.
> As a user, I do not care what language my editor is implemented in.
I do care. I don't like using Electron apps, even if I have to grudgingly use them a la VSCode. If an app is in Electron or some other slow framework like a Python GUI, my interest immediately drops to zero. If it's in Rust or some other low level language, at least I know it'll be fast.
Don't let the “built|written in Rust” taglines put you off either project.
Both are fast editors built by passionate teams offering compelling out-of-the box experiences. They're worth taking five minutes to download and try (or apply for the waitlist in the case of Zed).
Both are fast editors built by passionate teams offering compelling out-of-the box experiences. They're worth taking five minutes to download and try (or apply for the waitlist in the case of Zed).
[deleted]
Think this in a jokingly way: since only smart and dedicated people can master Rust, software written by these people must be good most of the time. Just like how literate people in ancient societies are mostly elite class. You don't expect a peasant to write a history book.
Of course, same as how our societies develop, when Rust inevitably become more popular, this perception will no longer hold. One day, Rust will join amongst C and C++ and become tool for everyone. Until then, "Written in Rust" is just a cheap but effective differentiation ad.
Of course, same as how our societies develop, when Rust inevitably become more popular, this perception will no longer hold. One day, Rust will join amongst C and C++ and become tool for everyone. Until then, "Written in Rust" is just a cheap but effective differentiation ad.
> As a user, I do not care what language my editor is implemented in.
Perhaps its a proxy for speed. You don't want your editor written in python.
Perhaps its a proxy for speed. You don't want your editor written in python.
Average joe-schmoe Neovim user here. My goal is not to emulate VS Code and other similar software. I enjoy Neovim for programming mainly because...
- First and foremost, I love the text editing features Vim has (eg. the movements, modes, keys etc). It just feels great on my hands.
- It's minimal. Well, you are free to make it as minimal or as bloated as you would like to ;)
- For me, it sort of gamifies text editing. I don't claim that using Vim makes me x-times more efficient at programming than someone else, but I do enjoy the thrill of learning a new, quicker way to make some changes.
- Vim/Neovim offers me a seemingly endless amount of things to learn. Some may see this as a negative thing, but I see it as a feature. It's truly like a skill or a hobby. You can learn the basics and be perfectly fine, but you can also dive deep into more ways to improve. I love this.
- I love how configurable it is, and also that you can actually learn about how it works.
- Also if I'm being honest, I feel like a myself and a lot of other Neovim users are basically masochists to some extent.
- First and foremost, I love the text editing features Vim has (eg. the movements, modes, keys etc). It just feels great on my hands.
- It's minimal. Well, you are free to make it as minimal or as bloated as you would like to ;)
- For me, it sort of gamifies text editing. I don't claim that using Vim makes me x-times more efficient at programming than someone else, but I do enjoy the thrill of learning a new, quicker way to make some changes.
- Vim/Neovim offers me a seemingly endless amount of things to learn. Some may see this as a negative thing, but I see it as a feature. It's truly like a skill or a hobby. You can learn the basics and be perfectly fine, but you can also dive deep into more ways to improve. I love this.
- I love how configurable it is, and also that you can actually learn about how it works.
- Also if I'm being honest, I feel like a myself and a lot of other Neovim users are basically masochists to some extent.
Agree that it gamifies text editing – vim motions are fun, even though I largely don't miss them in VS Code, or I use a vim extension when I do.
> …myself and a lot of other Neovim users are basically masochists to some extent.
It's great of you to say this, and heartwarming to see a sense of self-awareness on HN.
It's easy to rationalise our tech choices away (vim = speed, efficiency, freedom!). It's harder to admit that we may have chosen our tools simply because it's fun to walk a learning curve that runs sharply from pain to joy. Of course we could pick an easier tool! But then our path runs from apathy to apathy! And we'd be making it alongside people who think tools are just tools, instead of within a counterculture of likeminded people who think that tools are _everything_.
Maybe I should give neovim another shot…
> …myself and a lot of other Neovim users are basically masochists to some extent.
It's great of you to say this, and heartwarming to see a sense of self-awareness on HN.
It's easy to rationalise our tech choices away (vim = speed, efficiency, freedom!). It's harder to admit that we may have chosen our tools simply because it's fun to walk a learning curve that runs sharply from pain to joy. Of course we could pick an easier tool! But then our path runs from apathy to apathy! And we'd be making it alongside people who think tools are just tools, instead of within a counterculture of likeminded people who think that tools are _everything_.
Maybe I should give neovim another shot…
[deleted]
Helix is just very, very excellent. I've spent less than 5 minutes total configuring it and I really have virtually not a single complaint and there's WIP for the niceties that aren't present yet (sidebar/treeview, etc).
I installed it, had some LSPs already on path. I configured it to show LSP messages and that was about it. It's very cool how gosh darn productive I can be, in such a short time due to the command palette built in.
Seems like folks are taking note too. There's a few intro videos on YouTube that do a good job posted in the last few weeks; apparently some big Vim-guy streamer checked it out last week. Active Matrix room and constant code improvements. And native nix flakes support too ;)
Btw, I find it a bit weird to include VsCode and Helix here together. Helix is perfectly usable as a Vim replacement for all basic text editing tasks, and a superior zero-config alternative in countless other scenarios.
I installed it, had some LSPs already on path. I configured it to show LSP messages and that was about it. It's very cool how gosh darn productive I can be, in such a short time due to the command palette built in.
Seems like folks are taking note too. There's a few intro videos on YouTube that do a good job posted in the last few weeks; apparently some big Vim-guy streamer checked it out last week. Active Matrix room and constant code improvements. And native nix flakes support too ;)
Btw, I find it a bit weird to include VsCode and Helix here together. Helix is perfectly usable as a Vim replacement for all basic text editing tasks, and a superior zero-config alternative in countless other scenarios.
I'm looking forward to a treeview too!
https://github.com/helix-editor/helix/pull/2377
And subsequent icon support:
https://github.com/helix-editor/helix/pull/2869
> I find it a bit weird to include VsCode and Helix here together.
I work with people who declared config bankruptcy, switched from Emacs/Neovim to VS Code, and are perfectly happy and (maybe even more?) productive as a result.
VSC is not in the same category as vim but it seems to appeal because it's a halfway house between vim/Helix and a heavier IDE. John Carmack even said something similar about VSC in his Lex Fridman interview:
01:11:31.060 And I am super happy that that seems to be winning
01:11:33.540 over even a lot of the old Vim and Emacs people
01:11:36.140 that they're kind of like,
01:11:37.140 hey, visual studio code's maybe not so bad.
01:11:40.060 I am, that may be the final peacekeeping solution
01:11:43.260 where everybody is reasonably happy
01:11:45.620 with something like that.
https://karpathy.ai/lexicap/0309-large.html
https://github.com/helix-editor/helix/pull/2377
And subsequent icon support:
https://github.com/helix-editor/helix/pull/2869
> I find it a bit weird to include VsCode and Helix here together.
I work with people who declared config bankruptcy, switched from Emacs/Neovim to VS Code, and are perfectly happy and (maybe even more?) productive as a result.
VSC is not in the same category as vim but it seems to appeal because it's a halfway house between vim/Helix and a heavier IDE. John Carmack even said something similar about VSC in his Lex Fridman interview:
01:11:31.060 And I am super happy that that seems to be winning
01:11:33.540 over even a lot of the old Vim and Emacs people
01:11:36.140 that they're kind of like,
01:11:37.140 hey, visual studio code's maybe not so bad.
01:11:40.060 I am, that may be the final peacekeeping solution
01:11:43.260 where everybody is reasonably happy
01:11:45.620 with something like that.
https://karpathy.ai/lexicap/0309-large.html
For a perspective that hasn't been shared all ready, I like modal editing because I A) don't like to use the mouse any more than I have to and B) have awful memory when it comes to complicated chords of keyboard shortcuts. Except for the bare basics (switching modes, jumping to the start and end of lines, etc), I heavily rely on much easier to remember names of commands to interact with my editor. Like toggling line numbering: I'm sure there's some ctrl-alt-F4 esque chord to do it in VS Code, but that'll be much harder for me to remember than :set number.
For similar reasons, I prefer the command line to GUI-based applications, that all seem to be built around either a love of clicking through a long series of cascading menus, or memorizing obtuse shortcuts. TUI applications like Vim integrate much more readily with my other command line tools, so it creates a much more seamless workflow.
For similar reasons, I prefer the command line to GUI-based applications, that all seem to be built around either a love of clicking through a long series of cascading menus, or memorizing obtuse shortcuts. TUI applications like Vim integrate much more readily with my other command line tools, so it creates a much more seamless workflow.
> but that'll be much harder for me to remember than :set number
You could also do Ctrl+P on VSCode (or Ctrl+Shift+A on a Jetbrains IDE) and search for "line number". Command based interfaces are no longer unique to CLI tools.
You could also do Ctrl+P on VSCode (or Ctrl+Shift+A on a Jetbrains IDE) and search for "line number". Command based interfaces are no longer unique to CLI tools.
> why you chose it over VS Code
VS Code has always felt clunky to me. It always felt like a halfway house between the speed and simplicity of Vim and the maximalism offered by JetBrains IDEs. I also just generally don’t love GUI apps for code because I desire to be right in my shell.
NeoVim offers LSP, Tree Sitter, DAP, and easy extensibility to reach full parity with any IDE, but with the benefit of it being:
* Faster (both in processing speed but also in my workflow). I can navigate significantly faster in Vim than I can in any other editor. * More familiar, to me.
I can’t speak to Helix as I’ve never heard of it, but in general, the Vim community is very strong and long-lasting - it’s been a top tier editor for the past few decades and will likely continue to keep that place (albeit NeoVim is the currently favored flavor for me).
Beyond that, the extensibility of Neovim is unmatched in VSCode.
I also do most of my development in a VM and VS code remote shell is significantly slower for me than just ssh + neovim.
> huge amount of work, hoop jumping, and fragility to reach parity
This seems inaccurate. Maybe it’s because I use NixOS but my editor experience is literally the least fragile piece of software I use. I’ve ran into far more issues in both GoLand and VS Code than I have in Neovim. Perhaps because Neovim is less of a walled garden?
It took me about a weekend to properly learn Lua and how Neovim works, and after that, I was set.
> spent months tweaking
I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all. I don’t really touch my editor config unless I need to install a new LSP server - it always just works.
—
At the end of the day, the best tool is the one that enables you to be most productive. I find almost anything outside of the terminal clunky (the main exception is my browser).
VS Code has always felt clunky to me. It always felt like a halfway house between the speed and simplicity of Vim and the maximalism offered by JetBrains IDEs. I also just generally don’t love GUI apps for code because I desire to be right in my shell.
NeoVim offers LSP, Tree Sitter, DAP, and easy extensibility to reach full parity with any IDE, but with the benefit of it being:
* Faster (both in processing speed but also in my workflow). I can navigate significantly faster in Vim than I can in any other editor. * More familiar, to me.
I can’t speak to Helix as I’ve never heard of it, but in general, the Vim community is very strong and long-lasting - it’s been a top tier editor for the past few decades and will likely continue to keep that place (albeit NeoVim is the currently favored flavor for me).
Beyond that, the extensibility of Neovim is unmatched in VSCode.
I also do most of my development in a VM and VS code remote shell is significantly slower for me than just ssh + neovim.
> huge amount of work, hoop jumping, and fragility to reach parity
This seems inaccurate. Maybe it’s because I use NixOS but my editor experience is literally the least fragile piece of software I use. I’ve ran into far more issues in both GoLand and VS Code than I have in Neovim. Perhaps because Neovim is less of a walled garden?
It took me about a weekend to properly learn Lua and how Neovim works, and after that, I was set.
> spent months tweaking
I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all. I don’t really touch my editor config unless I need to install a new LSP server - it always just works.
—
At the end of the day, the best tool is the one that enables you to be most productive. I find almost anything outside of the terminal clunky (the main exception is my browser).
Thanks, some helpful insights here. (It sounds like the summary is, “set it up and don't fiddle with it too much.”)
I agree that the neovim community is great and neovim is of course very hackable, although there's always room to improve: an API for terminal UI would help a lot when writing neovim plugins and make everything feel more consistent, for example.
> I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all.
I built a neovim config from scratch, used built-in docs, community support, and well-known extensions when needed. I wrote small Lua plugins when I couldn't find extensions or workflows that worked for me. And I had fun doing it!
I got something good in a weekend, something very decent in a week or two, but still had a lot of gaps between what I had and what I wanted (session save, restore and quick switching; a Magit-like staging and forge management UI for GitHub CLI -driven PR management; invoking and managing long-running terminal processes from the editor; find/replace in large numbers of files across big projects with something more intuitive than a quickfix list; linting with something lighter-weight and easier to configure alongside LSP servers than ale; quicklists for LSP issues; a simple test runner with quicklist for errors; I can go on…).
After trying out extensions for some of those things but finding nothing that fit the bill, I played with Emacs and had a pretty similar experience there (weeks of work just to reach parity with VSC+a few extensions). I concluded I was wasting my time — it was pretty clear I was after an IDE more than a text editor at this point. VS Code seemed a nice in-between option. There are things I miss from vim/Emacs (speed, keyboard-driven workflow, getting to enjoy and celebrate editors with a community of likeminded weirdos), which is why I tend to get sucked in by these update announcements and discussions. But for the most part VSC is fine.
I agree that the neovim community is great and neovim is of course very hackable, although there's always room to improve: an API for terminal UI would help a lot when writing neovim plugins and make everything feel more consistent, for example.
> I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all.
I built a neovim config from scratch, used built-in docs, community support, and well-known extensions when needed. I wrote small Lua plugins when I couldn't find extensions or workflows that worked for me. And I had fun doing it!
I got something good in a weekend, something very decent in a week or two, but still had a lot of gaps between what I had and what I wanted (session save, restore and quick switching; a Magit-like staging and forge management UI for GitHub CLI -driven PR management; invoking and managing long-running terminal processes from the editor; find/replace in large numbers of files across big projects with something more intuitive than a quickfix list; linting with something lighter-weight and easier to configure alongside LSP servers than ale; quicklists for LSP issues; a simple test runner with quicklist for errors; I can go on…).
After trying out extensions for some of those things but finding nothing that fit the bill, I played with Emacs and had a pretty similar experience there (weeks of work just to reach parity with VSC+a few extensions). I concluded I was wasting my time — it was pretty clear I was after an IDE more than a text editor at this point. VS Code seemed a nice in-between option. There are things I miss from vim/Emacs (speed, keyboard-driven workflow, getting to enjoy and celebrate editors with a community of likeminded weirdos), which is why I tend to get sucked in by these update announcements and discussions. But for the most part VSC is fine.
If you use Neovim, can you share why you chose it over VS Code
Every time I try VS Code, I get frustrated within 10 minutes and close it.
It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.
I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?
But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed
I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.
I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:
* TreeSitter * LSP Diagnostics * LSP Trouble * LSP Saga * Git Signs * Git Gutter * Telescope * NvimTree * WhichKey * Indent Blankline * Dashboard * BufferLine * Lualine * Lightline * Neogit * vim-sneak * Fern * Barbar * Scrollbar * Mini
In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.
Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.
Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.
Every time I try VS Code, I get frustrated within 10 minutes and close it.
It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.
I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?
But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed
I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.
I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:
* TreeSitter * LSP Diagnostics * LSP Trouble * LSP Saga * Git Signs * Git Gutter * Telescope * NvimTree * WhichKey * Indent Blankline * Dashboard * BufferLine * Lualine * Lightline * Neogit * vim-sneak * Fern * Barbar * Scrollbar * Mini
In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.
Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.
Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.
I can't really agree that VS Code or Helix are "great out of the box". I haven't tried zed. VS Code feels really awful to me (note: this is probably just me) without weeks spent re-configuring it. Even then, it's _way_ too heavy for my laptop to run reliably. Maybe my brain just works differently, but I feel like VSCode fights against me at every turn. Helix is nifty, but also feels like it gets in my way more than it helps.
I've never understood the advantage of "rich development environments". The refactoring tools and other fancy aids seem to never work. I wind up using regexes + manual intervention anyway. Also, I don't want to use git through a gui. Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.
Syntax highlighting, linting, completion, and docs are all nice, but I have that in vim. I can run vim in the dev instance I'm ssh-ed into (which is 99.99% of how I work, anyway -- my work laptop is ancient and they won't replace it). I just can't see what those tools add, even for very large codebases.
My configuration for vim began in the 90's. I've never put that much work into it at any one time, though it has grown quite complex over time. There are a bunch of plugins I use manged in the config file. 90% of the functionality I need works without those plugins, but even when I need to install them from scratch it's easy to go from "scp config file over" to "full setup" with one command.
So in summary, I use vim because it's part of a larger set of standard unix-y tools that are heavily ingrained into muscle memory. The biggest advantage of vim in many ways is that it's a relatively rich environment (e.g. linting, syntax highlighting, doc hints, etc) that I can ctrl-Z to immediately be back in the terminal with. Other than that, it gets out of my way, and I don't think about the editor at all, I think about what I'm doing (decades of muscle memory helps a lot, though -- I'm incapable of not using vim keybindings to edit code, I think).
I should move over to neovim, but mostly haven't yet. That's more due to a couple of weird plugins than anything else, though.
I've never understood the advantage of "rich development environments". The refactoring tools and other fancy aids seem to never work. I wind up using regexes + manual intervention anyway. Also, I don't want to use git through a gui. Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.
Syntax highlighting, linting, completion, and docs are all nice, but I have that in vim. I can run vim in the dev instance I'm ssh-ed into (which is 99.99% of how I work, anyway -- my work laptop is ancient and they won't replace it). I just can't see what those tools add, even for very large codebases.
My configuration for vim began in the 90's. I've never put that much work into it at any one time, though it has grown quite complex over time. There are a bunch of plugins I use manged in the config file. 90% of the functionality I need works without those plugins, but even when I need to install them from scratch it's easy to go from "scp config file over" to "full setup" with one command.
So in summary, I use vim because it's part of a larger set of standard unix-y tools that are heavily ingrained into muscle memory. The biggest advantage of vim in many ways is that it's a relatively rich environment (e.g. linting, syntax highlighting, doc hints, etc) that I can ctrl-Z to immediately be back in the terminal with. Other than that, it gets out of my way, and I don't think about the editor at all, I think about what I'm doing (decades of muscle memory helps a lot, though -- I'm incapable of not using vim keybindings to edit code, I think).
I should move over to neovim, but mostly haven't yet. That's more due to a couple of weird plugins than anything else, though.
> Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.
People talk about vim nit being an IDE, but I think a lot of people think of the unix command line as their IDE.
People talk about vim nit being an IDE, but I think a lot of people think of the unix command line as their IDE.
I have been using vim since the late 90s, although the experience back then was much different. I don't think I really used plugins until around 2010 or so, and I was more into gvim until I moved to tmux + vim combo around 2016. So my nvim setup is not too fancy (sometimes I try plugins, if in two weeks I don't use them -or I don't even remember how they work-, I uninstall them).
Moved to neovim because it felt faster than vim 7.x and it was fresh and exciting (couldn't believe the progress the project was making in a short period of time, compared with vim). Then I stayed because of the native LSP support and nvim-metals (among others).
Things work, to the point that I'm not really using the editor but editing (if that makes sense). It is completely invisible to me. It is my editor.
Moved to neovim because it felt faster than vim 7.x and it was fresh and exciting (couldn't believe the progress the project was making in a short period of time, compared with vim). Then I stayed because of the native LSP support and nvim-metals (among others).
Things work, to the point that I'm not really using the editor but editing (if that makes sense). It is completely invisible to me. It is my editor.
Similar story here. I often liken it to a musician with their instrument, or a master blacksmith with their hammer - at some point the tool stops being a separate entity and becomes an extension of the person wielding it. I think the ability to have this comes from the fact the fundamentals of the tool are stable across decades.
> If you use Neovim, can you share why you chose it over VS Code
Just about 30 years of muscle memory for ed, then vi, eventually vim, and recently neovim. Also because one flavour or another is pretty much guaranteed to be available on any server I log into - as a contractor, it's handy to know there's a (to me) usable editor wherever I end up.
> I've spent months tweaking Neovim/Emacs configs in the past
I had a brief spell of Emacs madness at uni but then recovered and I've had pretty much the same vimrc since picking up vim modulo adding things like go-vim and surround in the last few years.
Just about 30 years of muscle memory for ed, then vi, eventually vim, and recently neovim. Also because one flavour or another is pretty much guaranteed to be available on any server I log into - as a contractor, it's handy to know there's a (to me) usable editor wherever I end up.
> I've spent months tweaking Neovim/Emacs configs in the past
I had a brief spell of Emacs madness at uni but then recovered and I've had pretty much the same vimrc since picking up vim modulo adding things like go-vim and surround in the last few years.
> pretty much guaranteed to be available on any server I log into
So is nano, the original comment hits the mark, why exactly can't you use a proper code editor via ssh? There's very little reason these days. Haven't used a terminal editor for a decade despite doing tons of work that many would instinctively reach for the same job.
VSCode and pretty much every other equivalent has modal editing if that's the sticking point here.
So is nano, the original comment hits the mark, why exactly can't you use a proper code editor via ssh? There's very little reason these days. Haven't used a terminal editor for a decade despite doing tons of work that many would instinctively reach for the same job.
VSCode and pretty much every other equivalent has modal editing if that's the sticking point here.
> nano [pretty much guaranteed to be available on any server]
Having just checked 5 of the servers I'm currently logged into, nano is missing on 3 of them. Although one of those 3 is cygwin which is weird in the first place.
> why exactly can't you use a proper code editor via ssh?
Well, vim is a proper code editor. If you mean VSCode, it's not available everywhere; been at plenty of places where installing/using non-approved software on work machines was forbidden. Also, and this is a minor point, kinda, but using (n)vi(m) remotely rather than VSCode gives me one/many windows fewer to manage on my local end - everything currently lives in iTerm2 and I only have one app to wrangle. Using VSCode would give me another one - unless it can do terminal emulation as well these days?
Having just checked 5 of the servers I'm currently logged into, nano is missing on 3 of them. Although one of those 3 is cygwin which is weird in the first place.
> why exactly can't you use a proper code editor via ssh?
Well, vim is a proper code editor. If you mean VSCode, it's not available everywhere; been at plenty of places where installing/using non-approved software on work machines was forbidden. Also, and this is a minor point, kinda, but using (n)vi(m) remotely rather than VSCode gives me one/many windows fewer to manage on my local end - everything currently lives in iTerm2 and I only have one app to wrangle. Using VSCode would give me another one - unless it can do terminal emulation as well these days?
What exactly is a “proper code editor”, and why does Neovim not fit the bill there?
The reason I still use emacs over helix or zed: elisp.
Not because I particularly like the language. But because I like that I can write something in a language that executes and accesses pretty much anything the editor can do.
Does helix or zed have the ability to do that? I didn't see it on their landing pages. What are the extensibility stories for these editors?
Not because I particularly like the language. But because I like that I can write something in a language that executes and accesses pretty much anything the editor can do.
Does helix or zed have the ability to do that? I didn't see it on their landing pages. What are the extensibility stories for these editors?
Don't know about hex/zed but Lua in neovim is just about as pleasant to use as Elisp is with Emacs. It's not quite the same thing since neovim's still largely written in C, where Emacs is largely written in Elisp. But most of the editor's features (including text manipulation) are exposed to Lua.
Lua is a nice language too, just lacking the stuff that makes the Lisp nerd in me happy.
Lua is a nice language too, just lacking the stuff that makes the Lisp nerd in me happy.
And you can use Fennel to hack Neovim, if you want to stick with a lispy language.
Neat!
Zed and Helix are both pretty new.
There's demand for plugin frameworks/scriptability in both but neither of them support it yet. I fully understand why people who need to script their editor are sticking with [neo]vim/Emacs — there are very few other options at the moment.
https://github.com/zed-industries/feedback/issues/388
https://github.com/helix-editor/helix/discussions/3806
There's demand for plugin frameworks/scriptability in both but neither of them support it yet. I fully understand why people who need to script their editor are sticking with [neo]vim/Emacs — there are very few other options at the moment.
https://github.com/zed-industries/feedback/issues/388
https://github.com/helix-editor/helix/discussions/3806
I use emacs. I have little desire to customize configs and spend hardly any time on it. Checking now, I haven't modified it since June, which means I haven't even installed any new packages (the equivalent of VSCode extensions) since then either.
Maybe I should spend more time on it, but my settings work for me and I can't really be bothered/find coding projects much more alluring than editing a config.
Why emacs, then? Mostly that I like the keybindings more than anything else. Emacs extensions in vs code are a poor imitation at best. I'm not really into modal editing either. Maybe I'd just have to spend the time to learn that, but I'm quite productive with emacs, so I don't see the incentive. I have keyboards with thumb clusters, so it's comfortable and quick to press key combinations in parallel. Switching between modes and executing key presses is inherently serial in comparison. I assume with practice I could get very quick at that as well -- after all, typing is also serial, but can still be fast. I just don't see any value proposition to switching.
Maybe I should spend more time on it, but my settings work for me and I can't really be bothered/find coding projects much more alluring than editing a config.
Why emacs, then? Mostly that I like the keybindings more than anything else. Emacs extensions in vs code are a poor imitation at best. I'm not really into modal editing either. Maybe I'd just have to spend the time to learn that, but I'm quite productive with emacs, so I don't see the incentive. I have keyboards with thumb clusters, so it's comfortable and quick to press key combinations in parallel. Switching between modes and executing key presses is inherently serial in comparison. I assume with practice I could get very quick at that as well -- after all, typing is also serial, but can still be fast. I just don't see any value proposition to switching.
Neovim is extensibility and versatility. If you want a rich development environment, you can put in the work, or use one of the many preconfigured environments, and turn neovim into that.
If you want a bare ultra fast, terminal text editor, neovim is that out of the box.
If your only after LSP, tree sitter, embedded terminal, neovim's got your back.
Basically, neovim embodies the beauty of Linux. Use and pay only for what you want.
If you want a bare ultra fast, terminal text editor, neovim is that out of the box.
If your only after LSP, tree sitter, embedded terminal, neovim's got your back.
Basically, neovim embodies the beauty of Linux. Use and pay only for what you want.
As a Vim user I particularly liked this tweet thread on the topic recently:
https://mobile.twitter.com/hillelogram/status/15676069643974...
The central point of the thread was that VS Code is designed to be extended by dedicated editor extension developers while Vim is designed to be extended by basically all users of Vim. There are tradeoffs to both approaches.
https://mobile.twitter.com/hillelogram/status/15676069643974...
The central point of the thread was that VS Code is designed to be extended by dedicated editor extension developers while Vim is designed to be extended by basically all users of Vim. There are tradeoffs to both approaches.
I enjoy a terminal workflow, and helix doesn't actually have vim key bindings and many years of vim use is hard to switch.
EDIT: I'm also a tmux user and I can't live without a replacement for this plugin: https://github.com/christoomey/vim-tmux-navigator
EDIT: I'm also a tmux user and I can't live without a replacement for this plugin: https://github.com/christoomey/vim-tmux-navigator
Check wezterm, it has something similar to tmux splits and it's nice.
Kitty also has this feature built in!
I should try it, I read a lot of users that like kitty in the unix porn community, but never gave it a try.
Overall, I like it. I enjoyed WezTerm as well, but found that it suffered incredible lag in Neovim. Honestly, if not for that, I probably would use WezTerm full time. But kitty does have some significantly nice features, especially if you use ssh a lot (which I do).
Will do! Currently using alacritty and enjoying that
+1. WezTerm is incredibly well done.
I actually loved Helix, but moved from it to Neovim for performance and customizability reasons. Helix becomes unusable with multi thousand line files, but I imagine it's something that will eventually be solved as the project matures. The customizability of Neovim is incredible, and I'm looking forward to trying Helix again when it has a plugin solution
I like "simple" editors: just text, completion when I ask for it (instead of popping up all the time), no distracting UI chrome, simple syntax highlights, etc. "Simple" is a bit of a misleading term, because even "stock Vim" (or Neovim) has a lot of IDE-like features. They just don't get in your way by default.
I tried VSCode, and after several hours I still hadn't turned off all the features that I found undesirable.
For me, personally, that nvchad thing seems horrendous. I don't know about Helix; maybe it's better, but I can't be arsed to check it out as I don't expect any productivity jump to be worth the effort.
I tried VSCode, and after several hours I still hadn't turned off all the features that I found undesirable.
For me, personally, that nvchad thing seems horrendous. I don't know about Helix; maybe it's better, but I can't be arsed to check it out as I don't expect any productivity jump to be worth the effort.
Helix has segfaulted within minutes every time I've tried it. Despite being written in rust. It might be better now, but they've already lost me.
I switched away from VSC because I grew frustrated with the constant lag and terrible loading times.
The modern native stuff is either MacOS only or a proprietary newcomer, leaving me with no trust that I can stick with it long term.
And I'm a Nix user, so neovim doesn't randomly break for me, all versions are pinned. And if stuff does break when I chose to update my pinned versions it's trivial to rollback.
I switched away from VSC because I grew frustrated with the constant lag and terrible loading times.
The modern native stuff is either MacOS only or a proprietary newcomer, leaving me with no trust that I can stick with it long term.
And I'm a Nix user, so neovim doesn't randomly break for me, all versions are pinned. And if stuff does break when I chose to update my pinned versions it's trivial to rollback.
I use VS Code for my day job because I can't be bothered to sink that much time into configuring my editor these days. But I recently setup NeoVim to play with Clojure since the most popular VS Code Clojure plugin (Calva) interacts poorly with vim keybindings. It was surprisingly easy to get setup (used the Conjure plugin) - NeoVim has come a long way in the years since I had last played with it.
> If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors [...]
I am using vim/neovim for almost 15 years now. I was introduced to vim within _days_ after I started programming. I have a workflow where I open and close my editor several times per minute (although I'm now slowly moving away from this workflow) - startup speed matters a lot for this, of course. I never bothered to learn another editor or IDE because of the speed I get with (neo)vim. Moving my hands away from the homerow for interacting with IDE features just feels like driving a Porsche in a 10mph zone. I have muscle memory in my hands for over 10 years now!
I switched from vim to neovim at around neovim 0.5 mostly for ideological reasons, but I stayed for lua based plugins and a IMO better community. I rewrote my complete neovim configuration (which I took over from vim of course) about a month ago to be pure Lua and to be more streamlined... I don't consider this work or hoop-jumping at all, but optimizing my editing environment to safe time when actually editing source code (or emails fwiw).
On a side-note, I also use vim-ish bindings for everything else, for me DE/WM, Email client (which uses neovim to write emails actually), etc etc. I just don't see a point in un-learning all this.
I am using vim/neovim for almost 15 years now. I was introduced to vim within _days_ after I started programming. I have a workflow where I open and close my editor several times per minute (although I'm now slowly moving away from this workflow) - startup speed matters a lot for this, of course. I never bothered to learn another editor or IDE because of the speed I get with (neo)vim. Moving my hands away from the homerow for interacting with IDE features just feels like driving a Porsche in a 10mph zone. I have muscle memory in my hands for over 10 years now!
I switched from vim to neovim at around neovim 0.5 mostly for ideological reasons, but I stayed for lua based plugins and a IMO better community. I rewrote my complete neovim configuration (which I took over from vim of course) about a month ago to be pure Lua and to be more streamlined... I don't consider this work or hoop-jumping at all, but optimizing my editing environment to safe time when actually editing source code (or emails fwiw).
On a side-note, I also use vim-ish bindings for everything else, for me DE/WM, Email client (which uses neovim to write emails actually), etc etc. I just don't see a point in un-learning all this.
I don't need parity with VS code. If I want LSP and all kinds of distractions, binging and bonging, and crap jumping out and highlighting at me... I'll use VS code (don't get me wrong, sometimes those distractions are useful).
Sometimes I need a terminal text editor. Something to quickly edit a config file, or perhaps even write something more substantial. Vim and Neovim are perfect and available on pretty much any machine which you'll have a terminal open to access.
Sometimes I need a terminal text editor. Something to quickly edit a config file, or perhaps even write something more substantial. Vim and Neovim are perfect and available on pretty much any machine which you'll have a terminal open to access.
[deleted]
I know you asked for Neovim users, but as an Emacs user, I'll respond:
> If you use Neovim, can you share why you chose it over VS Code
Who said you can't use both? Neovim is a text editor, and VS Code is an IDE. There is overlap, but they serve different purposes.
I use Emacs because it has a lot of capabilities that make little sense in an IDE. I don't think many people use VS Code for reading email, for example.
And I use VS Code when it's more convenient than Emacs (e.g. debugging).
> If you use Neovim, can you share why you chose it over VS Code
Who said you can't use both? Neovim is a text editor, and VS Code is an IDE. There is overlap, but they serve different purposes.
I use Emacs because it has a lot of capabilities that make little sense in an IDE. I don't think many people use VS Code for reading email, for example.
And I use VS Code when it's more convenient than Emacs (e.g. debugging).
Modal editing in VS Code is not good enough. I still use it for certain things. Just not the bulk of my programming.
When helix is more ready, I will probably switch to it.
When helix is more ready, I will probably switch to it.
I use both, there are certain nuances with helix right now, like exploring the project structure, there's a sidebar in the works, but is not ready yet, also when you need to create new files I find it easier to do it in vscode.
I really like working inside a terminal, and I like being able to navigate seemlessly between code tabs and terminal tabs as though they are one. I can do this easily in vim+tmux, I can't do this easily in IDEs where the mouse is considered first-class. I do miss certain features of IDEs, but being able to toggle between shells, tabs and code is my killer feature.
I just switched to this setup now... Before, I was using kate (which is very nice) but I switched exactly for the reason you've mentioned. terminal and editor in the same place.
Kinda just like the modal editing of vim and the features and improvements upon it by neovim.
These days I've been using the LunarVim suite of neovim enhancements and I like it quite a bit.
https://www.lunarvim.org/
95% of my coding workflow takes place in the terminal (along with tmux and iTerm2) and neovim fits very nicely there.
These days I've been using the LunarVim suite of neovim enhancements and I like it quite a bit.
https://www.lunarvim.org/
95% of my coding workflow takes place in the terminal (along with tmux and iTerm2) and neovim fits very nicely there.
vi (and in different ways, emacs) were designed for optimal editing productivity on low-bandwidth connections and low horsepower machines.
This created an imperative around efficiency per keystroke that, somewhat shockingly, remains the most thorough and successful mainstream attempt to get the most from every keystroke.
With modern technology and decades more experience it seems inevitable that someone could do better today (though even with those benefits not everyone is Bill Joy), but I’m not aware of anyone who has successfully attempted to beat vi/emacs for the “will learn arbitrarily hard tools to be fast” crowd, which necessarily counts the “my RSI is so bad I need my money’s worth out of every key press” crowd, and several other big blocks of badass hackers.
People still use these tools because they still have the highest ceilings on the effort/power scalability curve. That doesn’t make them right for everyone, but it makes them right for a lot of people.
This created an imperative around efficiency per keystroke that, somewhat shockingly, remains the most thorough and successful mainstream attempt to get the most from every keystroke.
With modern technology and decades more experience it seems inevitable that someone could do better today (though even with those benefits not everyone is Bill Joy), but I’m not aware of anyone who has successfully attempted to beat vi/emacs for the “will learn arbitrarily hard tools to be fast” crowd, which necessarily counts the “my RSI is so bad I need my money’s worth out of every key press” crowd, and several other big blocks of badass hackers.
People still use these tools because they still have the highest ceilings on the effort/power scalability curve. That doesn’t make them right for everyone, but it makes them right for a lot of people.
I use Neovim because I used Vim before it.
I used Vim because every GUI editor was an ugly, siloed proprietary mess that was mostly just wrapped around a bunch of open source command line tools, while Vim was an ugly, open source, programmable mess that was mostly just wrapped around a bunch of open source command line tools.
I used Vim because every GUI editor was an ugly, siloed proprietary mess that was mostly just wrapped around a bunch of open source command line tools, while Vim was an ugly, open source, programmable mess that was mostly just wrapped around a bunch of open source command line tools.
Because it's vim but better. I don't want an editor that uses, maybe, eighty megs and is constantly swapping!
I use Neovim exclusively for the past 4 years or so. Before that I used WebStorm + sometimes Vim for another 6 years or so. To this day I'm thankful to my colleague and mentor, who introduced me to the basics of Vim (you know, how to quit it and all that) saying "it get's pretty handy when you need to edit something on the server"; that was probably around 14 years ago.
WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition. The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.
At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line. And with resent native lsp & treesitter, it doesn't
I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.
Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs. Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.
So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.
WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition. The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.
At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line. And with resent native lsp & treesitter, it doesn't
I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.
Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs. Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.
So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.
What are you attempting to do with all that config hacking? I've used vi variants for years with pretty much the defaults.
I also use vscode and other IDEs. Why make it seem like one has to choose? That's like saying 'why do you use a hammer, i like screwdrivers better'.
I also use vscode and other IDEs. Why make it seem like one has to choose? That's like saying 'why do you use a hammer, i like screwdrivers better'.
I have a simple .vim setup which I can use across multiple machines: https://github.com/serprex/.vim (I know there's simpler out there; I haven't spent time pruning my config down)
I prefer sticking to full terminal UI
When I used vscode I was frustrated by vsvim's latency & missing features (macros tended to have holes)
I didn't start using vim until I'd been programming for a decade already. Before that I mostly used SciTE
You may be more susceptible to over tinkering. In the past few years the most I've tinkered with my setup was when I decided to try out neovim's lsp feature, where previously I'd been using coc.nvim
I prefer sticking to full terminal UI
When I used vscode I was frustrated by vsvim's latency & missing features (macros tended to have holes)
I didn't start using vim until I'd been programming for a decade already. Before that I mostly used SciTE
You may be more susceptible to over tinkering. In the past few years the most I've tinkered with my setup was when I decided to try out neovim's lsp feature, where previously I'd been using coc.nvim
[deleted]
I kind of take the best of both worlds. VSCode has a lot of functionality that Neovim lacks, particularly on rendering previews of things like Markdown and Mermaid. Even outside of UI stuff, VSCode's extension ecosystem has so much deeper integration with things (beyond the level of just text/code editing, I mean). The VSCode JS Debug Terminal is literally life-changing. No more needing to mess around with debugger configs for runtimes. Literally just run the code and it works.
Despite that, I still often feel limited by the vim binding plugin for VSCode. It's never a problem though, because Cmd+J toggles the terminal visibility, and I escape into Neovim there when I need it.
Despite that, I still often feel limited by the vim binding plugin for VSCode. It's never a problem though, because Cmd+J toggles the terminal visibility, and I escape into Neovim there when I need it.
I was a Vim user for a decade+ and recently switched to VSCode 100% because the Typescript integration is unmatchable, no matter how hard you try in NeoVim (and I tried hard).
If you're a front-end dev there's really nothing better. Also the https://www.tabnine.com/ integration feels like magic, it predicts the next block you're going to type with scary accuracy. I'm excited to see where AI IDE integration goes.
But I still hate how VSCode is like a browser that will grind to a halt if you install (or misconfigure) too many extensions.
If you're a front-end dev there's really nothing better. Also the https://www.tabnine.com/ integration feels like magic, it predicts the next block you're going to type with scary accuracy. I'm excited to see where AI IDE integration goes.
But I still hate how VSCode is like a browser that will grind to a halt if you install (or misconfigure) too many extensions.
Yeah I don't see why one would try to reproduce the VSCode experience inside vim or whatever.
Vim or neovim inside tmux are really nice, though. You can just use the normal general-purpose linux ecosystem rather than learning an IDE.
Vim or neovim inside tmux are really nice, though. You can just use the normal general-purpose linux ecosystem rather than learning an IDE.
The sunk cost fallacy is real.
Most important to me when I started tinkering with him was the speed/feature tradeoff, and portability. I was working on 7 machines at one point doing pretty quick edits of config files and Python scripts, so launch speed and availability across different environments drive me to vim.
Now there are alternatives, but back in 2015 these were all in their infancy. And now I _know_ vim and it keep adding more features. The incremental cost of adding language server support is much less than the cost of learning how to move around VSCode, so my (neo)vim config keeps growing slowly but surely
Most important to me when I started tinkering with him was the speed/feature tradeoff, and portability. I was working on 7 machines at one point doing pretty quick edits of config files and Python scripts, so launch speed and availability across different environments drive me to vim.
Now there are alternatives, but back in 2015 these were all in their infancy. And now I _know_ vim and it keep adding more features. The incremental cost of adding language server support is much less than the cost of learning how to move around VSCode, so my (neo)vim config keeps growing slowly but surely
- I have used vim for many years (15 maybe?), and once you have passed the initial learning curve (not so terrible, after you keep learning cool stuff even after years of use), it's useful for everything with the same shortcuts. I would actually spend more time learning something else like an new IDE. At the end, I have probably saved a lot of time by sticking to (neo)vim instead of following the latest trend.
- I like terminals because there is nearly nothing disturbing you, and it's usually quick to have something
- there are many little features that looks like nothing but are really really useful when you use them. I'm a big fan of C-a / C-x to increment / decrement a number, coupled with https://github.com/nishigori/increment-activator it's super useful (to change a boolean, a date, a number, etc). The "." to repeat last command, the "*" to search what is under the cursor are other great features. An occasional macro made with "q" may save a lot of time when you need to do a repetitive task, for refactoring for instance, and you can even repeat them according to some patterns with ":g". I'm not sure if those features have handy equivalents on other IDEs.
- I didn't spent that much time doing my config, just adding little changes here and there when necessary, over the years I've got a environment really adapted to my taste.
- I'm currently doing mostly Python, and vanilla (neo)vim is normally good enough, but I'm using Coc (https://github.com/neoclide/coc.nvim) for a little while, and it add a lot of helping stuff easily. Pyright + snippets are useful.
- when something cool happens somewhere else, you often have somebody adapting it to vim. I can use snippets and emmet which are occasionally very useful.
At the end, I don't feel the need to change, it works well, and over the time I could add some neat features to improve it (snippets, emmet, CoC, tagbar, etc). I'm not sure if changing to something like VScodium would worth the time to learn something new (and I like working with terminals).
- I like terminals because there is nearly nothing disturbing you, and it's usually quick to have something
- there are many little features that looks like nothing but are really really useful when you use them. I'm a big fan of C-a / C-x to increment / decrement a number, coupled with https://github.com/nishigori/increment-activator it's super useful (to change a boolean, a date, a number, etc). The "." to repeat last command, the "*" to search what is under the cursor are other great features. An occasional macro made with "q" may save a lot of time when you need to do a repetitive task, for refactoring for instance, and you can even repeat them according to some patterns with ":g". I'm not sure if those features have handy equivalents on other IDEs.
- I didn't spent that much time doing my config, just adding little changes here and there when necessary, over the years I've got a environment really adapted to my taste.
- I'm currently doing mostly Python, and vanilla (neo)vim is normally good enough, but I'm using Coc (https://github.com/neoclide/coc.nvim) for a little while, and it add a lot of helping stuff easily. Pyright + snippets are useful.
- when something cool happens somewhere else, you often have somebody adapting it to vim. I can use snippets and emmet which are occasionally very useful.
At the end, I don't feel the need to change, it works well, and over the time I could add some neat features to improve it (snippets, emmet, CoC, tagbar, etc). I'm not sure if changing to something like VScodium would worth the time to learn something new (and I like working with terminals).
What exactly is fragile about vim/neovim? I'd argue that they are incredibly stable, being as old as they are.
For another point I don't see being brought up, I love the .vimrc file. You can version control your entire editor config in one file. Other editors tend to spread config out across different files (one per plugin for example).
I've had to spend time configuring every editor I've used, but all that time is tracked and documented in vim. I can have everything set up instantly.
For another point I don't see being brought up, I love the .vimrc file. You can version control your entire editor config in one file. Other editors tend to spread config out across different files (one per plugin for example).
I've had to spend time configuring every editor I've used, but all that time is tracked and documented in vim. I can have everything set up instantly.
If you want to use Vim keybindings for the whole experience (not just the text editor panes). VSCode has plugins for Vim-editing, but not a complete experience. Helix has similar, but different bindings. Zed is still in private beta mode, so no idea what its like.
There’s others, too, but none seem to have a big and healthy community like (Neo)Vim.
There’s others, too, but none seem to have a big and healthy community like (Neo)Vim.
I use VSCode, but I installed the vim plugin which makes it handle like vim for user inputs. Best of both worlds IMHO.
Nice customisation, but it still doesn't have the 'list of tab' vertical window that VSCode has, and I'll never switch to an editor which doesn't have this.
Even if I find VSCode not very responsive..
you can use neovim inside of vscode. it's pretty alright with only a few things that are rocky. I like it. got that modern gui affordances with the plugin ecosystem and lsp baked into it hard but also the normal/visual mode power.
Thanks, I use VSCodeVim at the moment because even though it's not using “real vim” under the hood the performance has been more consistent for me.
I revisit VSCode Neovim periodically but end up switching back after a day or so due to consistent freezing and cursor jitter (even with an empty nvim config and very few other VS Code extensions). I'll keep trying it out, though.
I revisit VSCode Neovim periodically but end up switching back after a day or so due to consistent freezing and cursor jitter (even with an empty nvim config and very few other VS Code extensions). I'll keep trying it out, though.
For me the reason is mostly because of the speed of editing in Vim for me is blazing fast compared to what I can do in VSCode. Many of the most-frequently used Vim commands are just baked into my muscle memory at this point.
For me it's simple. My hands are already on my keyboard, and I already have my terminal open. For most of my programming I use whatever Jet Beans IDE my company has licenses for.
https://v2.onivim.io
I was always bummed OniVim v2 didn't take off.
It was a native IDE but fully supported VS Code plugin system.
I was always bummed OniVim v2 didn't take off.
It was a native IDE but fully supported VS Code plugin system.
I've found the extra complexity of IDEs unecessary and detrimental to my productivity. I like to keep it simple: neovim with LSP and fzf in a tmux session.
Neovim user here. I also use VS Code and especially the Jetbrain products for IDEs. Yet, Neovim is for me just an editor.
- I like I can use the same editor on any platform. I'm a wearable computing nerd having several HMDs and small devices (devterm, raspberry pie, etc.).
- If it's my own platform, it's easy to compile it. It runs in a console and most of my plugins work on embedded, desktop and server systems. (could even compile it and use it on my hacked google glass .. with a twiddler one handed keyboard :D ).
- I like the use of keyboard-only and mode switching. It's more an hobby than anything else. I also use qtbrowser and Nyxt.
Also growing up with a very different Microsoft ("Linux is evil communism"), I still feel uncomfortable using VSCode.
- I like I can use the same editor on any platform. I'm a wearable computing nerd having several HMDs and small devices (devterm, raspberry pie, etc.).
- If it's my own platform, it's easy to compile it. It runs in a console and most of my plugins work on embedded, desktop and server systems. (could even compile it and use it on my hacked google glass .. with a twiddler one handed keyboard :D ).
- I like the use of keyboard-only and mode switching. It's more an hobby than anything else. I also use qtbrowser and Nyxt.
Also growing up with a very different Microsoft ("Linux is evil communism"), I still feel uncomfortable using VSCode.
I tried to use Helix and really liked it, but had to stick with Neovim because of Copilot.
I also really like Helix. Looking forward to:
- Reload of files changed on disk: https://github.com/helix-editor/helix/pull/2653
- Autosave: https://github.com/helix-editor/helix/pull/3178
- Git/SCM support: https://github.com/helix-editor/helix/issues/227
- Extensions (potentially enabling Copilot support): https://github.com/helix-editor/helix/pull/2949
- Reload of files changed on disk: https://github.com/helix-editor/helix/pull/2653
- Autosave: https://github.com/helix-editor/helix/pull/3178
- Git/SCM support: https://github.com/helix-editor/helix/issues/227
- Extensions (potentially enabling Copilot support): https://github.com/helix-editor/helix/pull/2949
vim, or at least vi, is something you can pretty much expect to be existing on any system you ssh into. If you are comfortable with vim, you have the editor part sorted no matter what system you are dropped into to debug/whatever.
neovim/vim are lightning fast, and since they are usually installed on remote servers as well it is nice to have a consistent experience editing files whether I am working locally or in a remote shell somewhere.
Helix is nice but Zed development speed appears to be a bit slow for my liking.
besides being efficient text editor, I must say it's also a hobby for me. I just enjoy endlessly configuring it and writing little vim scripts.
Neovim is one of those things that seem maybe cool, but I just can't find a reason to switch. Vim works just fine for me, I don't know what I would be getting by switching, and I'd probably waste some time porting my config and workflow to whatever the differences are (I'm a heavy user of :terminal).
I switched to neovim because of LSP (Language server protocol) support. I know there are libraries (or whatever cool kids call it these days), which brings this functionality to og vim, but the lsp integration in neovim just works so nicely out of the box.
og vim does not have full lsp out of the box. However it does have the the api and options to implement one easily.
see: https://vimhelp.org/channel.txt.html#language-server-protoco... https://vimhelp.org/channel.txt.html#channel-mode
see: https://vimhelp.org/channel.txt.html#language-server-protoco... https://vimhelp.org/channel.txt.html#channel-mode
Hold on, you don't need anything like Ale or CoC to run LSPs in neovim?
Nope, NeoVim has native LSP support https://neovim.io/doc/lsp/
Plugins built with lua, lsp, treesitter for syntax highlighting are the big ones.
https://neovimcraft.com — For neovim specific plugins
https://neovimcraft.com — For neovim specific plugins
Yes, treesitter is a sea change. Besides the quick and error-tolerant syntax highlighting it provides, plug-ins which use it to manipulate syntax are remarkably fast and accurate.
Yeah it's a tough one. I've switched back and forth relatively freely over the years, but now that new VimScript (vim9 script) has breaking changes and neovim will not be supporting it, it's probably time to pick a pony.
I may end up sticking with og vim but my heart has always been with neovim. regular vim would undoubtedly still be stuck in the stone age (including with no :terminal) had neovim not started some competition. I get the feeling that VimL's evolution was done in a way that made it quite difficult or impossible for neovim to merge/rebase into. Hopefully that wasn't intentional.
I may end up sticking with og vim but my heart has always been with neovim. regular vim would undoubtedly still be stuck in the stone age (including with no :terminal) had neovim not started some competition. I get the feeling that VimL's evolution was done in a way that made it quite difficult or impossible for neovim to merge/rebase into. Hopefully that wasn't intentional.
The creator of Neovim's LSP integration is currently working on a VimL9 JIT compiler to make Vim9 plugins work for Neovim (early stages). So you still may be able to stay on the fence.
"Exciting progress on vim9script => Nvim-Lua transpiler”: https://twitter.com/Neovim/status/1575455161186664451
Vim has had :terminal since version 8.1 [1].
[1]: https://gist.github.com/mahemoff/8967b5de067cffc67cec174cb3a...
[1]: https://gist.github.com/mahemoff/8967b5de067cffc67cec174cb3a...
Going somewhat off memory here, but my recollection is that was like 3 or 4 years after neovim's first release.
That’s true.
The whole reason there ever was a vim 8 was neovim and the pressure it applied to implement async plugins and terminal.
Without neovim, we'd still be on vim 7.xxxxx
Without neovim, we'd still be on vim 7.xxxxx
Vim user for 15+ years here. Switched to neovim last December to try out Github's Copilot plugin (which only supported neovim), and it was basically a drop-in replacement for vim. And I haven't looked back.
I'm also a heavy user of terminal though, and that was the one thing I spent extra time on, because there were subtle differences that I didn't like. If you give neovim a shot again, try this in your ~/.config/nvim/init.vim (aside: I do miss the simpler path of ~/.vimrc):
I'm also a heavy user of terminal though, and that was the one thing I spent extra time on, because there were subtle differences that I didn't like. If you give neovim a shot again, try this in your ~/.config/nvim/init.vim (aside: I do miss the simpler path of ~/.vimrc):
" Neovim's default terminal mode bindings aren't great.
" This makes them behave like vim's.
tnoremap <Esc> <C-\><C-n><C-w>
tnoremap <C-w> <C-\><C-n><C-w>
"Always enter the terminal in insert mode
autocmd BufWinEnter,WinEnter,BufEnter term://* startinsert
autocmd TermOpen,TermEnter * startinsert
command! -nargs=0 Terminal :vsplit | term
From the opposite side, I decided a few years ago to use neovim in place of vim, and there were no drawbacks to making the switch for me.
Then again, most of my time these days I spend in JetBrains Clion with Vim emulation, as it is much better suited to the kinds of projects that I currently work on than Vim or Neovim ever was. So take my opinion on Vim vs Neovim with a grain of salt.
Then again, most of my time these days I spend in JetBrains Clion with Vim emulation, as it is much better suited to the kinds of projects that I currently work on than Vim or Neovim ever was. So take my opinion on Vim vs Neovim with a grain of salt.
The big downside is having to install neovim. Good old vim is in macos, git bash on windows, any random vm you’re thrown into… I also use the vim plugin for intellij et al, but I use vim on all the raspberry pi’s, weird windows boxes with some issue, and so forth. It’s already everywhere and neovim isn’t.
Neovim has official appimage-based binaries that you can simply download, chmod, and execute. Just move it into your personal binaries directory and you're done.
Treesitter integration is a bit easier in neovim IMHO (but I haven't tried to make it work with vim too much.)
Newer plugin development seems to be much more on the nvim side than vim as well. (Although I do feel fzf is superior to telescope, at least out of the box.)
I'm happy neovim exists, it rekindled vim development.
Also, someone correct me if I'm wrong, but isn't the bus factor 1 on vim?
Newer plugin development seems to be much more on the nvim side than vim as well. (Although I do feel fzf is superior to telescope, at least out of the box.)
I'm happy neovim exists, it rekindled vim development.
Also, someone correct me if I'm wrong, but isn't the bus factor 1 on vim?
> Also, someone correct me if I'm wrong, but isn't the bus factor 1 on vim?
There's a bunch of people who are "members" of the vim organisation on GitHub. I don't know if they have full admin privileges or just commit/issue access. I never really understood why this has to be a problem in the first place: can always clone the repo and continue working on it if Bram disappears.
There's a bunch of people who are "members" of the vim organisation on GitHub. I don't know if they have full admin privileges or just commit/issue access. I never really understood why this has to be a problem in the first place: can always clone the repo and continue working on it if Bram disappears.
-------
Source, if anyone wants to dig deeper: https://www.gnu.org/licenses/vim-license.txt
Unsure why I'm being downvoted but okay.
vim/vim is licensed under the Vim License
There are no restrictions on using or distributing an unmodified copy of the software. Parts of the software may also be distributed, but the license text must always be included. For modified versions a few restrictions apply. The license is GPL compatible, you may compile the software with GPL libraries and distribute it.
Source, if anyone wants to dig deeper: https://www.gnu.org/licenses/vim-license.txt
Unsure why I'm being downvoted but okay.
In additional to all the features that others mention, I chose to support the Neovim project. It's a more open alternative without a BDFL that is willing to move forward and modernize the editor, drop support for ancient platforms, and regularly release improvements.
A big deal was splitting the editor engine from the interface so that it's embeddable in other editors.
A big deal was splitting the editor engine from the interface so that it's embeddable in other editors.
Your .vimrc will probably work as-is without much work from you.
Plus Vim and Neovim can co-exist on the same machine without an issue to try it out [1].
[1]: https://neovim.io/doc/user/nvim.html#nvim-from-vim
Plus Vim and Neovim can co-exist on the same machine without an issue to try it out [1].
[1]: https://neovim.io/doc/user/nvim.html#nvim-from-vim
Back in the day, Neovim has always felt about three times snappier than Vim (I think it was Vim 7.2). Also, I don't remember if the newer versions of Vim have it, but Neovim has native LSP support, which is also very nice.
Telescope is must have for me.
https://github.com/nvim-telescope/telescope.nvim
https://github.com/nvim-telescope/telescope.nvim
Personally I switched purely because of lua, I don't really gel with the vimscript.
[deleted]
I switched because the cursor handling is nicer in neovim. It puts a bar when editing so you can see if you're inserting before or after a character, and an underscore when operating on a single character (like after pressing "r").
The former sucks to do in vim, I couldn't get it working in tmux at all, and I don't think the latter is possible?
Apart from that I'm treating it like vim and using all my existing vimrc and vimscript plugins. It's been good.
The former sucks to do in vim, I couldn't get it working in tmux at all, and I don't think the latter is possible?
Apart from that I'm treating it like vim and using all my existing vimrc and vimscript plugins. It's been good.
Neovim is vim 8 compatible. It _also_ supports LUA script for config and plugins, has native LSP support, and runs much more efficiently.
You can run your current .vimrc using neovim.
You can run your current .vimrc using neovim.
>Neovim ... supports LUA script for config and plugins
https://news.ycombinator.com/item?id=32624308
----
I've been using Neovim for several years now. Not for any real reason, other than "Let's try 'new & shiny'" when it first emerged. Last week I thought I'd finally get round to converting my existing Neovim init.vim config [which had itself been inherited and developed from my earlier Vim .vimrc one] to Lua [not a language I'd ever used before. But the syntax looked fairly straightforward].
What a waste of time! The easy stuff [enabling/disabling various options] was easy. But then it's easy in Vimscript too. The difficult stuff [defining autocmds, managing my plugins] was either completely ignored in every single "convert your init.vim to to init.lua" tutorial I read... or required wrapping the existing Vimscript block in
vim.cmd[[ ... ]]YMMV if you're actively developing plugins and want to use a more widely utilised language to write them in. But for configuring Neovim itself, Lua is more hassle than it's worth.
The Neovim API is more fully baked now than it was.
I went through the same thing back in the day… now it’s a breeze and I’ve never coded in Lua before. Part of the problem was different users suggesting different things.
"Build your first Neovim configuration in lua” is a good introduction [1].
[1]: https://vonheikemen.github.io/devlog/tools/build-your-first-...
I went through the same thing back in the day… now it’s a breeze and I’ve never coded in Lua before. Part of the problem was different users suggesting different things.
"Build your first Neovim configuration in lua” is a good introduction [1].
[1]: https://vonheikemen.github.io/devlog/tools/build-your-first-...
I found this very helpful when switching to nvim recently. Kudos to the author for having the nvim config on github and making videos explaining how he set it all up:
https://github.com/LunarVim/Neovim-from-scratch
https://www.youtube.com/watch?v=ctH-a-1eUME&list=PLhoH5vyxr6...
https://github.com/LunarVim/Neovim-from-scratch
https://www.youtube.com/watch?v=ctH-a-1eUME&list=PLhoH5vyxr6...
I gotta say, the Neovim guys are killin’ it on YouTube and Twitch.
They’re reaching a new generation of Neovim/Vim users.
They’re reaching a new generation of Neovim/Vim users.
Couple things. Over the last year, the lua API has expanded. You can now do almost everything with only lua! Autocmds, commands, plugin management - all in lua. Even key-mappings can call lua closures directly! And with treesitter, the strings in `vim.cmd([[...]])` calls get highlighted as vimscript.
Not saying you should give it another go, just that your info is out of date ;)
Not saying you should give it another go, just that your info is out of date ;)
when i switched to neovim, vim did not have :terminal and that was the real killer feature to me. neovim also had better async communication support than vim did. vim caught up, but in the meantime i had already gone full on nvim. Now, with the lua support, there's no way to make my config compatible between the two, and i'm "stuck" on nvim.
Embrace, extend, extinguish!
the reasons why i switched to nvim:
- configuring in lua (much easier than vimscript, imho) - treesitter - built-in language server protocol - plugins (id call them "projects") like telescope
- configuring in lua (much easier than vimscript, imho) - treesitter - built-in language server protocol - plugins (id call them "projects") like telescope
I tried moving to neovim from vim mainly to try Copilot.
I think the selling points are supposed to target plugin authors, and people who like to use a ton of plugins.
However, I would imagine that well over 90% of Vim users don't use a single plugin. At all. They defined some look and feel defaults in a ".vimrc" file 10+ years ago, and never thought about it again. At least that's my user profile, anyway.
So to me, the NeoVim story is mostly Internet drama, about some salty devs who didn't get their patches merged and have been publicly jihading ever since. It's not enough to merely use NeoVim, you have be angry about it.
However, I would imagine that well over 90% of Vim users don't use a single plugin. At all. They defined some look and feel defaults in a ".vimrc" file 10+ years ago, and never thought about it again. At least that's my user profile, anyway.
So to me, the NeoVim story is mostly Internet drama, about some salty devs who didn't get their patches merged and have been publicly jihading ever since. It's not enough to merely use NeoVim, you have be angry about it.
Must every neovim release thread be brigaded by naysayers asking the same question for the 1000000th time? If you don't like its value proposition, don't use it. Simple. Keep using your IDE or whatever solution you prefer. This is almost exclusively happens in (neo)vim threads, and its so utterly distracting. That there is an entire community camped around neovim should answer your question about why anyone choses it over {insert non-vim solution}
But then what would we talk about? The update?
We recently started providing standardized neovim centric dotfiles setup to developers at our startup and this setup has improved productivity quite a lot.
Our neovim "distribution" is highly geared towards our tech stack (Golang etc.) and provides fzf based command palette.
See: https://github.com/fluxninja/dotfiles
We aren't using neovim's built-in LSP as we found it to be a bit immature. Instead we are providing coc.nvim.
Our neovim "distribution" is highly geared towards our tech stack (Golang etc.) and provides fzf based command palette.
See: https://github.com/fluxninja/dotfiles
We aren't using neovim's built-in LSP as we found it to be a bit immature. Instead we are providing coc.nvim.
[deleted]
I really wish neovim could ship usable default colorscheme and round out its lsp support with autocompletion. Treesitter isn’t for me; it’s slower to open files and I have no idea how people make sense of so many different color groups.
Still sticking with vanilla vim and CoC for the time being, they’re rock solid.
Still sticking with vanilla vim and CoC for the time being, they’re rock solid.
Treesitter isn’t for me; it’s slower to open files
I certainly haven’t experienced any slowness with opening files with Neovim with Treesitter. It certainly enables much better syntax highlighting, among other things [1]. If anything, it’s faster than the regex-based syntax highlighting that Vim traditionally used.
CoC is a 3rd party LSP plugin that works with Vim and Neovim.
[1]: https://neovim.io/doc/treesitter/
I certainly haven’t experienced any slowness with opening files with Neovim with Treesitter. It certainly enables much better syntax highlighting, among other things [1]. If anything, it’s faster than the regex-based syntax highlighting that Vim traditionally used.
CoC is a 3rd party LSP plugin that works with Vim and Neovim.
[1]: https://neovim.io/doc/treesitter/
Treesitter is slower to parse a file initially but quicker at handling incremental changes. You probably won’t notice unless you open a huge source file.
Never used Treesitter, but I'd assume all this happens async? I.e., does Neovim actually block text editing untill the parsing is finished or do you just see unstyled content until it finishes?
(I'd just be surprised if anything new worked that way in 2022, let alone something built for async like Neovim.)
(I'd just be surprised if anything new worked that way in 2022, let alone something built for async like Neovim.)
It blocks text editing until it finishes.
This is planned for the next release: https://github.com/neovim/neovim/issues/14790
> usable default colorscheme
What's wrong with the default colorscheme?
What's wrong with the default colorscheme?
That looks pretty good, I don't know what the default colour scheme looks like, but if you are proposing this as an improvement I hope it gets in.
[deleted]
I feel the proliferation of plugins has made the whole vim/neovim echo system too complicated and overwhelming to adapt for a new user.
1. Vim itself has a learning curve
2. There are many great plugins, but if they don't work for you, then unless you are an advanced user, it is impossible to get everything working without wasting a day
3. I find it weird that to get a vim plugin to work, I might have to install llvm and do a compilation and prey that all the dependencies have been satisfied
What's bad is that while neovim tries to make vim much more functional with bunch if plugins, they barely stay stable.
I don't know why but even if I install same plugins with same config on various machines of same Linux distro version, some just throw errors on every launch while others tend to work and it's getting to the point of annoyance to keep using it.
It does feel like it's piling up parts hoping they don't fall apart.
Using vs code with remote config does make it feel saner.
I don't know why but even if I install same plugins with same config on various machines of same Linux distro version, some just throw errors on every launch while others tend to work and it's getting to the point of annoyance to keep using it.
It does feel like it's piling up parts hoping they don't fall apart.
Using vs code with remote config does make it feel saner.
A text editor without a well rounded GUI story isn't worth it for me. There are all these desperate projects each with their own focus, ranging from "simple graphics acceleration" to "tons of bells and whistles, animations and ad-hoc UI extensions".
UI should be thought out at PRs and issues, but the same people who develop the main core. But they don't have to, because they're making a terminal application, which has its use cases.
But I so no reason why I should type my text in a terminal, when I can use a proper GUI application.
And I'm not even suggesting VSCode, even Emacs is better in this regard, which is what I use.
UI should be thought out at PRs and issues, but the same people who develop the main core. But they don't have to, because they're making a terminal application, which has its use cases.
But I so no reason why I should type my text in a terminal, when I can use a proper GUI application.
And I'm not even suggesting VSCode, even Emacs is better in this regard, which is what I use.
One of the main features of NeoVim over VIM is that NeoVIM can be embedded into other programs and new GUIs can be built that use libvim. There are now programs you can download that do that, for example [1]. Certainly, this is still an experimental line of software and I don't use the NeoVIM GUIs and don't claim that this has been proven a success yet, but there are some encouraging signs.
https://github.com/topics/neovim-guis
https://github.com/topics/neovim-guis
I’ve used a few of the Neovim GUIs; they each have a different take on UI/UX for a Neovim GUI.
I’ve been using VimR the longest, which is a Mac-native GUI for Neovim: https://github.com/qvacua/vimr
I’ve been using VimR the longest, which is a Mac-native GUI for Neovim: https://github.com/qvacua/vimr
By vim user count alone, I would conjecture that the venn circle of
philosophically opposed devs has more people insisting on the absence of
a GUI story, than those insisting on one.
Of course the vast majority of devs use whatever suits them, GUI or not.
And you couldn't have picked an editor with a worse GUI story.
Of course the vast majority of devs use whatever suits them, GUI or not.
And you couldn't have picked an editor with a worse GUI story.
Do you have any refs/links of UI thought out at PRs and issues that you think are good examples?
> A text editor without a well rounded GUI story isn't worth it for me.
ed is the standard text editor.
https://www.gnu.org/fun/jokes/ed-msg.html
ed is the standard text editor.
https://www.gnu.org/fun/jokes/ed-msg.html
You're right. An environment that's all text and generally uses fixed width fonts is not at all the proper place to run an editor for dealing text that is best understood by displaying it with fixed width fonts.
The terminal is superior. You are just not skilled enough or advanced enough in thought to imagine what an interface can truly be.
Your terminal application is an emulator of a decades old technology originally used in physical consoles, with layers upon layers of enhancements that add support for colors, cursor control, etc. At it's core, it's just a grid of characters. The GUI as a platform is quite literally a superset of the terminal, for example because the terminal emulator app is a GUI itself. Hacking the grid of characters to render lines as if it was a GUI is hardly "superior".
I say all that as an avid neovim user myself by the way. On mac/linux I use it through the terminal, on Windows I use it through the QT application.
I say all that as an avid neovim user myself by the way. On mac/linux I use it through the terminal, on Windows I use it through the QT application.
The new generation of terminals are nothing like what you’re describing: GPU acceleration, full color support, font shaping, support for ligatures, built-in support for multiplexing, SSH and more.
WezTerm [1] is probably the best example right now but there are others.
These aren’t your father’s terminals.
[1]: https://wezfurlong.org/wezterm/
WezTerm [1] is probably the best example right now but there are others.
These aren’t your father’s terminals.
[1]: https://wezfurlong.org/wezterm/
Of course they are. Your new generation terminals still use decade old protocols, using the same escape sequences to control the cursor position, colors etc.
The "lines" and other UI elements you see in those next generation terminals when you run TUI apps like neovim are still simple characters aligned next to each other to look like a line etc.
Stuff like GPU acceleration is only another layer which was put on top of all of that. At the core they're still using the same old technology.
The "lines" and other UI elements you see in those next generation terminals when you run TUI apps like neovim are still simple characters aligned next to each other to look like a line etc.
Stuff like GPU acceleration is only another layer which was put on top of all of that. At the core they're still using the same old technology.
OTOH it's already probably a couple decades since some more fresh terminal emulator projects have popped up that kick a bit into the old cruft and provide both lightweight stuff and actual drawing routines for specific stuff. From a graphics dev pov it's not nonsense to decide for rendering on a grid, even for UI, i see it a bit like voxel 3D engines.
So i'm really not sure the "layers upon layers" critique is well suited for terminals, in comparison with say some qt/gtk/electron/<your gui>. Also GP is mentioning emacs, which is mostly the same old cruft as a terminal emulator.
So i'm really not sure the "layers upon layers" critique is well suited for terminals, in comparison with say some qt/gtk/electron/<your gui>. Also GP is mentioning emacs, which is mostly the same old cruft as a terminal emulator.
A real terminal or a fake one drawn ontop of a gui emulating deacades old cruft?
Complete madness and inefficiency.
Complete madness and inefficiency.
Just built it from source on a beta of macOS Ventura… everything went smoothly. These guys have done a great job.
Congrats on the release!
Long live simple, non-proprietary, open editors which can be extended infinitely: Emacs & Vim (and their derivatives) FTW.
Long live simple, non-proprietary, open editors which can be extended infinitely: Emacs & Vim (and their derivatives) FTW.
This is possibly my favourite kickstarted project. I use this every day and got far more than my contribution was worth. Quite happy.
My latest thing is I use it with C-x C-e in the terminal and copilot.vim to get shell autocompletions!
My latest thing is I use it with C-x C-e in the terminal and copilot.vim to get shell autocompletions!
They added a msi installer since 0.6 so that's pretty cool
Dumb question; what's an msi installer?
The installer for Windows https://en.wikipedia.org/wiki/Windows_Installer
I've been a Neovim user since inception -- I love the sane default configuration, the pruning away of old and obsolete "compatible" mode things, and the async and terminal support were killer features. When LSP support landed I was pretty firmly set.
I hate Lua, though, and more and more of the neovim ecosystem is moving in that direction. And now that vim has caught up on the async and terminal and LSP support I'm finding it hard to justify staying on neovim, except for the burden of sane-ifying my configuration.
VimL9 looks fantastic though -- VimScript has always been awkward but very domain-specific; VimL9 moves away from awkwardness but keeps the domain-specificity. Lua is not domain-specific enough, and the debugging and documentation are not good enough for me to pick it up in a pinch.
I think it's likely that I'll be making the switch back to vim9 in the near future, although I'll probably give Kakoune a try again before committing.
I hate Lua, though, and more and more of the neovim ecosystem is moving in that direction. And now that vim has caught up on the async and terminal and LSP support I'm finding it hard to justify staying on neovim, except for the burden of sane-ifying my configuration.
VimL9 looks fantastic though -- VimScript has always been awkward but very domain-specific; VimL9 moves away from awkwardness but keeps the domain-specificity. Lua is not domain-specific enough, and the debugging and documentation are not good enough for me to pick it up in a pinch.
I think it's likely that I'll be making the switch back to vim9 in the near future, although I'll probably give Kakoune a try again before committing.
I've tried using neovim for C++ dev but keep ending back in either vscode with intellisense or YCM on Vim. I don't know if I'm just misconfiguring things but I haven't been able to get autocomplete working correctly. Any tips?
You'll need to configure clangd or ccls correctly with neovim's lsp, which in turn requires your build chain to be clean. It's definitely a huge time sink. Feel free to email me if you have specific issues!
I was doing a school project in c++ and I tried configuring ccls but in the end I just gave up and did the project without LSP. Like you said it came with some prebuilt tooling and ccls did not feel particularly beginner friendly to get working as I am not familiar at all with the c++ toolchain.
It (mostly) worked out of the box in another project with only some minor quirks though
It (mostly) worked out of the box in another project with only some minor quirks though
I've also tried using vim/neovim etc. several times but had the same problem. Recently I've tested lunarvim and autocomplete worked out of the box (with Go).
https://github.com/hrsh7th/nvim-cmp should be the ticket
Finally I can get off the dev branch (which has been extremely stable though)
Any neovim based "gtk vim" app on linux?
gVim is so slow for me, can literally see the window text redraw from top to bottom, where sublime text or vscode switching tabs or scrolling is near instantaneous.
gVim is so slow for me, can literally see the window text redraw from top to bottom, where sublime text or vscode switching tabs or scrolling is near instantaneous.
Something like https://neovide.dev/index.html ?
That's a LONG list of fixes & features. I'm fairly new to vim (using Neovim as an IDE to learn Rust) but I'm very tempted to pull and build this release.
I use vscode and neovim. Both have their benefits.
Neovim is my main driver for reviewing/editing code. I have a few plugins and many personal functions/key bindings.
Vscode is great for quick copy/paste text and their plugin ecosystem. Ie working with azure has been a dream with vscode.
Neovim is my main driver for reviewing/editing code. I have a few plugins and many personal functions/key bindings.
Vscode is great for quick copy/paste text and their plugin ecosystem. Ie working with azure has been a dream with vscode.
can't have a vim discussion without someone bringing up emacs
Emacs gas sub-par treesitter support and will go by default with eglot which is ok but nowhere as polished as the lsp experience in Neovim.
I still haven’t recovered from the last couple updates… I’ll probably be making the switch to VIM very soon.
It's impressive to see what the Neovim community has built — preconfigured setups like https://nvchad.com/ are especially wild. But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed, which are pretty great out of the box, and which were built to be used as rich development environments instead of extensible text editors.
I've spent months tweaking Neovim/Emacs configs in the past and I ultimately end up conceding that I'd rather spend that time hacking on projects instead of my editor config. I do feel the pull of these editors, though. I'd love to understand what those who stick with them are doing differently, other than perhaps being more susceptible to sunk cost fallacies. :-)