3 ms·

Yeah its basically a Do it Yourself kit, not sure if you got the message I wrote in my comment. That is a negative, not a positive. Majority of the people don't

by kamaal 4y ago

Yeah its basically a Do it Yourself kit, not sure if you got the message I wrote in my comment. That is a negative, not a positive. Majority of the people don't have the time, or in many cases competence to spend several man months/years building things like these. Even if you do, you still won't be close to the complete vscode experience.

Accacin 4y ago
It's a negative for you, but not for me :) I guess that's why different editors exist.
likeclockwork 4y ago
You're not the target audience.
camgunz 4y ago
There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done. I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim. From my point of view, if you asked me to switch to VSCode, I probably wouldn't ever be as productive as I am now. This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working. Some people do go ham with their configs, and it's super cool that that's possible (something you can't really do with IDEs). But I think most people probably install a few plugins/language servers, set a few variables for modelines or whatever, and they're good.
- kamaal 4y ago
  >>There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done. You just explained the difference in this very statement yourself. Installing a plugin in vscode is a one step process. Installing it in vim is going on shopping spree for a car first, then using the car to go on shopping spree using that car. Along the way being knowledgeable enough to occasionally service the car. >>I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim. Nearly my whole career is basically writing ginormous quantities of Perl/Python/C over terminals, and I happen to be one of the heaviest users of vi(m)/emacs, on Solaris/AIX machines, then FreeBSD and now Linux. I still believe macros are the most magical things you can every touch in any piece of tech. These days I do nearly every other kind of development, and on several different platforms. And honestly speaking, merely hours of using vscode was enough to convince to use better tools to do my job, nothing wrong with that. Its just vscode does a lot more than being a code palette. >>This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working. As a old vi(m) user, my biggest productivity steals come from learning the native design choices, and learning to use them well. This is the same philosophy I carry over to vscode as well. The thing here is magically enough vscode does a lot of things really well out of the box.
  - camgunz 4y ago
    > Installing it in vim is going on shopping spree for a car first, then using the car to go on shopping spree using that car. Again, I think you're coming from a place of a lot of experience w/ VSCode and less in Vim. I needed PlantUML for something, so I: - Googled for 'vim plantuml' - Went to https://github.com/weirongxu/plantuml-previewer.vim https://github.com/weirongxu/plantuml-previewer.vim - Added "Plug 'weirongxu/plantuml-previewer.vim'" and "Plug 'akit/plantuml-syntax'" to my init.vim - Ran ":source ~/.config/nvim/init.vim" - Ran ":PlugInstall" At least to me, this is the same as opening up the plugin catalog in VSCode and picking stuff. --- I do a lot of varied development across different tech too: React, C, Svelte, Python/FastAPI/Django, Go, Lua, various SQLs, protobufs, JSON, CSVs... just all kinds of stuff. I've found Vim to not only be adequate, but excel. Maybe VSCode is great at all of these things, but that's not my point. My point is Vim works for me in the case you're describing, lots of different kinds of development on several different platforms. > The thing here is magically enough vscode does a lot of things really well out of the box. I think this is maybe the crux of our disagreement: you're pretty anti-config. I'm not wild about config either, some people's .vimrc files make me shudder, and when I learned about EMACS config bankruptcy I laughed out loud haha. But like, I like that I can set my default tabstop and shiftwidth, or change it per-language. I like that I can set hlsearch and incsearch. And I like that I can drop my config on almost any machine running and I'm in my element. There's a balance to strike, for sure, and maybe it is nice to sort of live out of a suitcase for your work life as it were. But for me, I've enjoyed decorating my work home.

by kamaal 4y ago

Accacin 4y ago

It's a negative for you, but not for me :) I guess that's why different editors exist.

likeclockwork 4y ago

You're not the target audience.

camgunz 4y ago

There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done. I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim. From my point of view, if you asked me to switch to VSCode, I probably wouldn't ever be as productive as I am now. This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working. Some people do go ham with their configs, and it's super cool that that's possible (something you can't really do with IDEs). But I think most people probably install a few plugins/language servers, set a few variables for modelines or whatever, and they're good.

kamaal 4y ago
>>There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done. You just explained the difference in this very statement yourself. Installing a plugin in vscode is a one step process. Installing it in vim is going on shopping spree for a car first, then using the car to go on shopping spree using that car. Along the way being knowledgeable enough to occasionally service the car. >>I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim. Nearly my whole career is basically writing ginormous quantities of Perl/Python/C over terminals, and I happen to be one of the heaviest users of vi(m)/emacs, on Solaris/AIX machines, then FreeBSD and now Linux. I still believe macros are the most magical things you can every touch in any piece of tech. These days I do nearly every other kind of development, and on several different platforms. And honestly speaking, merely hours of using vscode was enough to convince to use better tools to do my job, nothing wrong with that. Its just vscode does a lot more than being a code palette. >>This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working. As a old vi(m) user, my biggest productivity steals come from learning the native design choices, and learning to use them well. This is the same philosophy I carry over to vscode as well. The thing here is magically enough vscode does a lot of things really well out of the box.
- camgunz 4y ago
  > Installing it in vim is going on shopping spree for a car first, then using the car to go on shopping spree using that car. Again, I think you're coming from a place of a lot of experience w/ VSCode and less in Vim. I needed PlantUML for something, so I: - Googled for 'vim plantuml' - Went to https://github.com/weirongxu/plantuml-previewer.vim https://github.com/weirongxu/plantuml-previewer.vim - Added "Plug 'weirongxu/plantuml-previewer.vim'" and "Plug 'akit/plantuml-syntax'" to my init.vim - Ran ":source ~/.config/nvim/init.vim" - Ran ":PlugInstall" At least to me, this is the same as opening up the plugin catalog in VSCode and picking stuff. --- I do a lot of varied development across different tech too: React, C, Svelte, Python/FastAPI/Django, Go, Lua, various SQLs, protobufs, JSON, CSVs... just all kinds of stuff. I've found Vim to not only be adequate, but excel. Maybe VSCode is great at all of these things, but that's not my point. My point is Vim works for me in the case you're describing, lots of different kinds of development on several different platforms. > The thing here is magically enough vscode does a lot of things really well out of the box. I think this is maybe the crux of our disagreement: you're pretty anti-config. I'm not wild about config either, some people's .vimrc files make me shudder, and when I learned about EMACS config bankruptcy I laughed out loud haha. But like, I like that I can set my default tabstop and shiftwidth, or change it per-language. I like that I can set hlsearch and incsearch. And I like that I can drop my config on almost any machine running and I'm in my element. There's a balance to strike, for sure, and maybe it is nice to sort of live out of a suitcase for your work life as it were. But for me, I've enjoyed decorating my work home.