3 ms·
Is there really any truth to the superior customizability (he calls it a Personalized Development Environment) claimed here? VSCode extensions can change crazy
by SebastianKra 3y ago
Is there really any truth to the superior customizability (he calls it a Personalized Development Environment) claimed here?
VSCode extensions can change crazy stuff such as [1], and are also more numerous. I don't see much of an advantage to terminal-vim apart from performance and perhaps an inherent joy of building your own tools.
[1] https://marketplace.visualstudio.com/items?itemName=hoovercj.vscode-power-mode https://marketplace.visualstudio.com/items?itemName=hoovercj...
- linsomniac 3y agoMy take is that the customizability comes from the init.lua being more right there for you to look at and modify. LunarVim comes with a great set of plugins, but whenever I want to customize something I have to go and start digging to figure out what and where it's happening, how to adjust around it, etc...
- petepete 3y agoTJ actually has a video on this very topic https://www.youtube.com/watch?v=QMVIJhC9Veg https://www.youtube.com/watch?v=QMVIJhC9Veg The tl;dw is that the term 'PDE' means the tool requires some work in order to personalise, but because neovim exposes a robust API that work is fun and rewarding. Additionally, he makes the point that because you configure it in the same language as you script it with (lua), you have much greater control over how all the pieces fit together.
- SebastianKra 3y agoThat's a very reasonable justification. My only gripe is his requirement that the majority of users must make use of the scripting system in order for the program to be considered a PDE. If only 1% of all IntelliJ users ever use the Program Structure Interface or the powerful Live-Templating system, that's still a respectable number in total. And it also doesn't mean IntelliJ is less personalizable. Maybe a better term would be a DIY-DE.
- hinell 3y agoThat's nice but I don't really like when they rename some APIs.. That brings breaking changes you know.
- danielvaughn 3y agoRight now I'm building a vscode plugin that renders a webpage directly in the editor. I'm absolutely sure that the vim/neovim proponents are right about how much faster you can be with vim motions, but it'll never match the versatility of vscode primarily because it's built on top of web technologies.
- angra_mainyu 3y agoI think that's pretty much going against the vim mentality of offloading tasks to the appropriate tools. This is the kind of thing I would expect to see in emacs. That said, I can't imagine ever wanting to have a website render in my own editor, that's the kind of thing I'd like to use my target browser for.
- tpmoney 3y agoFor me the most common reason for rendering a web page in the editor is to have a side by side view of the markdown document I’m editing. I like using mark down to write basic documentation and tutorials and not having to have a render-> open in the browser step just makes that smoother. Yes I could have two windows side by side and yes I could have file events and watch for the markdown to be saved and kick off a render and kick off the browser refresh… but I can also just open a second pane in VSCode and let it do all of that for me.
- angra_mainyu 3y agoBut why not just have the browser in a split window? I don't think I've ever been able to do web dev without the browser open side by side. Also, most markdown ssg's have hot-reloading.