6 ms·

Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its

by pronik 11mo ago

Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.

torben-friis 11mo ago
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity. I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
- skydhash 11mo ago
  VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
  - torben-friis 11mo ago
    What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result. My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults. For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
    - t_mahmood 11mo ago
      Yeah, now see, you need to do that for every programming language, or tool for vscode. With Lazyvim you get all at once. And you can ignore many plugins if you want, Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities
      - skydhash 11mo ago
        There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool. Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.
      - torben-friis 11mo ago
        >Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled. I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.
        skydhash 11mo ago
        No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim. With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.
  - slaymaker1907 11mo ago
    You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.
    - iLemming 11mo ago
      > incredibly easy compared to getting them to edit some vim/emacs config Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system. There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity. Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise. I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them. Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.
skydhash 11mo ago
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
- iLemming 11mo ago
  > VSCode is familiar in its UX That's by design. It must have appealing looks and employ every trick from psychology books to get you to try it and keep using it. You don't have to be a genius to realize that a for-profit corporation with a $3 trillion market cap, spending millions on building a code editor with no direct licensing model; that they are distributing for "free" is not some kind of unseen goodwill; That shit eventually will generate billions in downstream Azure/services revenue. What is it if not a trivial ROI? It is a "loss leader" in traditional business terms, but a strategic necessity for cloud/services dominance. VSCode is essentially a Trojan horse for the Microsoft developer services ecosystem - a mental prison that is designed to be easy to get in but hard to escape. In comparison - vim/emacs have not a single profit motive; their network effect works differently; Yes, there's no entity with trillion dollar market cap to keep the pace with vscode, but no deprecation risks, no corporate pivot that ever is a treat to lock-in your data or your workflow or compatibility with older hardware. Vim & Emacs win by not being a loss leader for anything. Who can ever predict what happens 5–10–20 years from now? Who can guarantee that some evil CEO wouldn't replace Nadella and secretly start implementing changes in the strategy that would change the essence and the meaning of being a programmer? It is already assumed that every dev has to use GitHub and to know VSCode at least on some basic level today. What if tomorrow your employers would be able to analyze your telemetry data to "measure" your performance? What if the use of anything but VSCode as the code editor would simply be banned?
deleted 11mo ago
[deleted]
totetsu 11mo ago
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
frumplestlatz 11mo ago
I’ve been using emacs for very many years, and have a configuration that has evolved over a decade. I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great. Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE. VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.
- iLemming 11mo ago
  > requires an enormous amount of hacking to make a usable IDE. When you're using it for one, specific purpose, like an IDE for specific language(s), then yes, sure, it may feel like that. Yet Emacs is so much more. It's not an IDE (but it could be); it's not [the best] source control tool; it's not [greatest] note taking app; it's not an [amazing] mail client; it's not [most beautiful] pdf reader; nor a [feature rich] terminal app; etc. Emacs is not even an editor, to be brutally honest. It's not the greatest concrete implementation of any of these things. What Emacs actually is - it's a concrete implementation of an abstract idea - a Lisp REPL with a baked-in text editor into it. That, for a second, is an absolutely fascinating commodity. Once you grok the essence of that idea, it's really difficult not to see the extreme value of it. I'm sorry, I just have hard time to believe anyone who says: "used it for many years... yet abandoned it anyway". It typically means that they've been using it from a narrow, small focused point of view, without ever exploring the possibilities that "true" Lisp REPL can grant them. I just don't see myself ever escaping Emacs, because there's simply no practical, comparable alternatives to it. Comparing VSCode to Emacs is like comparing it to Thunderbird - you didn't like how Emacs handled your emails and now using something else? Congrats, and that's just fine, only it's not fair and proper comparison by any means.
  - frumplestlatz 11mo ago
    I have a job to get done, and my job isn’t screwing around with my Emacs configuration. And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place. I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wasted so much time making Emacs usable for my purposes.
cholantesh 11mo ago
>that thing is overwhelming with all its popups, hovers, sidebars etc. I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.
pxc 11mo ago
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life. Likewise, I find VSCode overstimulating and, for lack of a better word, rude. I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around. I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.
- t_mahmood 11mo ago
  IntelliJ shines when you use the command pallet, keyboard shortcuts, and IdeaVIM Double shift, to bring up the pallet, and start typing. Though it also have a ton of shortcuts, and shortcuts can be assigned for almost every command. Try this: https://plugins.jetbrains.com/plugin/9792-key-promoter-x/ https://plugins.jetbrains.com/plugin/9792-key-promoter-x/ Whenever you don't use keyboard shortcut for any action, this suggests you the available keyboard shortcut.
  - iLemming 11mo ago
    IntelliJ is an amazing feat of software engineering, there's no denying that. I'm not saying that to make you (or any other WebStorm/Pycharm/etc. user) feel better - I know that from years of dedicated use. I just want to share my anecdotal, personal story. I used IntelliJ professionally for almost a decade. I learned some advanced and undocumented features. I've collaborated with Jetbrains team members to help improving the features. It felt like I work for them. I still occasionally receive YouTrack notification emails for the bugs I posted circa 2009, that are still not fixed today, btw. IntelliJ is to blame for why my transition to Emacs took me two years - I carried the fear of investing too much into a new thing. I feared of liking it, and someday not finding some features I was so attached to in IntelliJ. I was scared that I will be intellectually and emotionally "locked in", while I was already vendor locked-in and condemned to be using IntelliJ forever. I was so wrong - not only have I found everything I needed, and more, I have developed a true hacker's mindset. Honestly, the only regret I still carry today, even after years of Emacs use, is that I did not attempt to learn it sooner. I no longer experience FOMO - I can easily pick up IntelliJ whenever I want again, I just haven't found a real, pragmatic reason to do so. In fact, I do fire it up on occasion, just to get the feel of how things evolving there, to steal some good ideas, etc. > and IdeaVIM Gary Bernhardt famously said - "There's no such thing as vim-mode". And to the degree, he was right - pretty much every editor/IDE that tries to integrate Vim features invariable ends up having glaring deficiencies. IdeaVIM is good enough, but only to the point - for an expert vimmer it may feel annoying. VSCode vim experience is similar, and Sublime as well - there's really no good comparison between them to say which one is really "better", they all have a spectrum of weird, quirky behaviors. There's one notable exception - Evil-mode in Emacs is fantastically good - sometimes you even forget that it's not a built-in feature, but a third-party extension, an afterthought. > shortcuts can be assigned for almost every command In Emacs, you can bind keys to anything, conversely - everything is a command - every keypress, every mouse click and mouse-scroll. And since Emacs is inherently a modal editor, you can do stuff like binding commands to a double, triple, etc. keypresses. Like for example, when I'm typing fast, to autofix most recent typo I'd just tap comma twice - this is just one example of unbelievably fast way to stay focused. Most devs, once they find their favorite tool would settle with it and don't even explore other options. "I don't have time for that.", "I don't want to be building my editor", "I am already so good with what I have, why?", they would say. My suggestion is to always stay skeptical of current choices and curious about unknown. It's not the concrete implementations, but rather abstract ideas that may grant some surprising and unexpected benefits.
jrm4 11mo ago
Here's the thing (as someone who did Emacs for a year and then gave it up) The possibility and ease of interoperability with other general program styles is far more important that the idea is given. Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)
solumunus 11mo ago
If you struggle with VS Code you must struggle with everything.
nsonha 11mo ago
Does not take any coding ability configue it. Out of the box you can search for any setting and even if you edit the json config directly you get autocomplete.

by pronik 11mo ago

torben-friis 11mo ago

Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity. I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.

skydhash 11mo ago
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
- torben-friis 11mo ago
  What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result. My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults. For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
  - t_mahmood 11mo ago
    Yeah, now see, you need to do that for every programming language, or tool for vscode. With Lazyvim you get all at once. And you can ignore many plugins if you want, Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities
    - skydhash 11mo ago
      There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool. Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.
    - torben-friis 11mo ago
      >Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled. I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.
      - skydhash 11mo ago
        No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim. With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.
- slaymaker1907 11mo ago
  You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.
  - iLemming 11mo ago
    > incredibly easy compared to getting them to edit some vim/emacs config Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system. There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity. Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise. I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them. Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.

skydhash 11mo ago

VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.

iLemming 11mo ago
> VSCode is familiar in its UX That's by design. It must have appealing looks and employ every trick from psychology books to get you to try it and keep using it. You don't have to be a genius to realize that a for-profit corporation with a $3 trillion market cap, spending millions on building a code editor with no direct licensing model; that they are distributing for "free" is not some kind of unseen goodwill; That shit eventually will generate billions in downstream Azure/services revenue. What is it if not a trivial ROI? It is a "loss leader" in traditional business terms, but a strategic necessity for cloud/services dominance. VSCode is essentially a Trojan horse for the Microsoft developer services ecosystem - a mental prison that is designed to be easy to get in but hard to escape. In comparison - vim/emacs have not a single profit motive; their network effect works differently; Yes, there's no entity with trillion dollar market cap to keep the pace with vscode, but no deprecation risks, no corporate pivot that ever is a treat to lock-in your data or your workflow or compatibility with older hardware. Vim & Emacs win by not being a loss leader for anything. Who can ever predict what happens 5–10–20 years from now? Who can guarantee that some evil CEO wouldn't replace Nadella and secretly start implementing changes in the strategy that would change the essence and the meaning of being a programmer? It is already assumed that every dev has to use GitHub and to know VSCode at least on some basic level today. What if tomorrow your employers would be able to analyze your telemetry data to "measure" your performance? What if the use of anything but VSCode as the code editor would simply be banned?

deleted 11mo ago

[deleted]

totetsu 11mo ago

I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..

frumplestlatz 11mo ago

I’ve been using emacs for very many years, and have a configuration that has evolved over a decade. I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great. Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE. VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.

iLemming 11mo ago
> requires an enormous amount of hacking to make a usable IDE. When you're using it for one, specific purpose, like an IDE for specific language(s), then yes, sure, it may feel like that. Yet Emacs is so much more. It's not an IDE (but it could be); it's not [the best] source control tool; it's not [greatest] note taking app; it's not an [amazing] mail client; it's not [most beautiful] pdf reader; nor a [feature rich] terminal app; etc. Emacs is not even an editor, to be brutally honest. It's not the greatest concrete implementation of any of these things. What Emacs actually is - it's a concrete implementation of an abstract idea - a Lisp REPL with a baked-in text editor into it. That, for a second, is an absolutely fascinating commodity. Once you grok the essence of that idea, it's really difficult not to see the extreme value of it. I'm sorry, I just have hard time to believe anyone who says: "used it for many years... yet abandoned it anyway". It typically means that they've been using it from a narrow, small focused point of view, without ever exploring the possibilities that "true" Lisp REPL can grant them. I just don't see myself ever escaping Emacs, because there's simply no practical, comparable alternatives to it. Comparing VSCode to Emacs is like comparing it to Thunderbird - you didn't like how Emacs handled your emails and now using something else? Congrats, and that's just fine, only it's not fair and proper comparison by any means.
- frumplestlatz 11mo ago
  I have a job to get done, and my job isn’t screwing around with my Emacs configuration. And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place. I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wasted so much time making Emacs usable for my purposes.

cholantesh 11mo ago

>that thing is overwhelming with all its popups, hovers, sidebars etc. I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.

pxc 11mo ago

I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life. Likewise, I find VSCode overstimulating and, for lack of a better word, rude. I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around. I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.

t_mahmood 11mo ago
IntelliJ shines when you use the command pallet, keyboard shortcuts, and IdeaVIM Double shift, to bring up the pallet, and start typing. Though it also have a ton of shortcuts, and shortcuts can be assigned for almost every command. Try this: https://plugins.jetbrains.com/plugin/9792-key-promoter-x/ https://plugins.jetbrains.com/plugin/9792-key-promoter-x/ Whenever you don't use keyboard shortcut for any action, this suggests you the available keyboard shortcut.
- iLemming 11mo ago
  IntelliJ is an amazing feat of software engineering, there's no denying that. I'm not saying that to make you (or any other WebStorm/Pycharm/etc. user) feel better - I know that from years of dedicated use. I just want to share my anecdotal, personal story. I used IntelliJ professionally for almost a decade. I learned some advanced and undocumented features. I've collaborated with Jetbrains team members to help improving the features. It felt like I work for them. I still occasionally receive YouTrack notification emails for the bugs I posted circa 2009, that are still not fixed today, btw. IntelliJ is to blame for why my transition to Emacs took me two years - I carried the fear of investing too much into a new thing. I feared of liking it, and someday not finding some features I was so attached to in IntelliJ. I was scared that I will be intellectually and emotionally "locked in", while I was already vendor locked-in and condemned to be using IntelliJ forever. I was so wrong - not only have I found everything I needed, and more, I have developed a true hacker's mindset. Honestly, the only regret I still carry today, even after years of Emacs use, is that I did not attempt to learn it sooner. I no longer experience FOMO - I can easily pick up IntelliJ whenever I want again, I just haven't found a real, pragmatic reason to do so. In fact, I do fire it up on occasion, just to get the feel of how things evolving there, to steal some good ideas, etc. > and IdeaVIM Gary Bernhardt famously said - "There's no such thing as vim-mode". And to the degree, he was right - pretty much every editor/IDE that tries to integrate Vim features invariable ends up having glaring deficiencies. IdeaVIM is good enough, but only to the point - for an expert vimmer it may feel annoying. VSCode vim experience is similar, and Sublime as well - there's really no good comparison between them to say which one is really "better", they all have a spectrum of weird, quirky behaviors. There's one notable exception - Evil-mode in Emacs is fantastically good - sometimes you even forget that it's not a built-in feature, but a third-party extension, an afterthought. > shortcuts can be assigned for almost every command In Emacs, you can bind keys to anything, conversely - everything is a command - every keypress, every mouse click and mouse-scroll. And since Emacs is inherently a modal editor, you can do stuff like binding commands to a double, triple, etc. keypresses. Like for example, when I'm typing fast, to autofix most recent typo I'd just tap comma twice - this is just one example of unbelievably fast way to stay focused. Most devs, once they find their favorite tool would settle with it and don't even explore other options. "I don't have time for that.", "I don't want to be building my editor", "I am already so good with what I have, why?", they would say. My suggestion is to always stay skeptical of current choices and curious about unknown. It's not the concrete implementations, but rather abstract ideas that may grant some surprising and unexpected benefits.

jrm4 11mo ago

Here's the thing (as someone who did Emacs for a year and then gave it up) The possibility and ease of interoperability with other general program styles is far more important that the idea is given. Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)

solumunus 11mo ago

If you struggle with VS Code you must struggle with everything.

nsonha 11mo ago

Does not take any coding ability configue it. Out of the box you can search for any setting and even if you edit the json config directly you get autocomplete.