Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive.
I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
Vim 9.0
171–180 of 272 posts
Re: Vim 9.0
#172Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
Use vim inside vs code right?
Re: Vim 9.0
#173Vim was the 4th most loved editor in 2021 at 69.7% (5th most wanted) [1], while Neovim was the most loved at 82.4% (11th most wanted). [1] https://insights.stackoverflow.com/survey/2021#section-most-...
…by the Stackoverflow crowd.
Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it.
Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
Re: Vim 9.0
#174Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
I would be very interested in a write up of why you prefer VSCode, if you can spare the time!
Re: Vim 9.0
#175Earlier quoted context omitted.
…by the Stackoverflow crowd.
Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it. Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (…
Thank you for explicitly stating the implications of what "...by the SO crowd" means. It wasn't obvious to me at all.
Re: Vim 9.0
#176Earlier quoted context omitted.
open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible. It is fully open source. Open source does not mean the maintainer is under the obligation to add features, or integrate PRs. [0]: https://opensource.org/osd [1]: https://www.gnu.org/licenses/vim-license.txt
I think you mistake the parent's point. Vim's code is certainly open source (I don't think anyone disputes that), but its development model is not the one we've come to be comfortable with. Moolenar maintains an iron grip on vim, and controls what goes in (and what doesn't) much more strictly than many other open source projects. That is certainly his prerogative, but it's also the prerogative of others to not like t…
> the development model is not the one we've come to be comfortable with
Says who? There are many free software projects, with public source code and free licenses, that are not developed openly. For example, lua itself (on which neovim is based). The lua team are adamant on not accepting external patches. And that is perfectly alright, and not contradictory with neither the letter nor the spirit of free software.
Re: Vim 9.0
#177Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
No offence but these types of comments are starting to look like AI generated
Re: Vim 9.0
#178Earlier quoted context omitted.
tabstop is how far the cursor moves when you press tab. shiftwidth is how far text moves when you shift it with >> or Normally you'd set them both to the same value so that indenting blocks of code with >> or There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with > round themselves to the nearest multiple of shiftwidth.
i've always used 0i\t\t\t\t...\esc to shift. never occurred to me to use >>. probably because the three keystroke savings didn't register with me. but that's what I mean, once I learn the basics, the rest are just gravy that don't stick in my memory.
Using for shifts becomes even more powerful when combined with a movement, e.g. indenting 20 lines of code at once: 20>> or indenting an entire {} block (including braces) >a{ or an entire block (not including braces) >i{
> i've always used 0i\t\t\t\t...\esc to shift.
Also consider I instead of 0i (it's not quite identical, but should serve the same purpose).
Re: Vim 9.0
#179Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
I would be very interested in a write up of why you prefer VSCode, if you can spare the time!
I'm someone else, but I did the same thing 5 years ago.
For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful.
When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales.
I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
Re: Vim 9.0
#180Earlier quoted context omitted.
I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience. https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
My understanding is that treesitter doesn't do anything with indentation. I believe the issues described in the linked issues are neovim specific. So it should be possible in theory to use treesitter data to calculate indents, though it seems difficult.
Treesitter does do indentation, but not well, and it is the sole mechanism of indentation for the Helix editor. Therein lies the problem.