To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?

Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.

I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.

With that said, i'll be quite glad that we're moving towards standardizing (of sorts) a code editor protocol so that new editors don't suffer from lack of tooling. It will be great to see a single set of tooling (formatting, linting, imports, syntax checking, etc) plug into any new editor that might pop up.

Switching editors has enough friction, tooling shouldn't be one.

Right now, for most people: very much yes.

Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.

Fair point. However: Between the default keybindings of Netbeans on Windows or Linux and the simplicity of customising it to my hearts content I haven't found any reason to abandon it.

I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.

Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years.

Yea, i definitely agree there. It's also that GUI IDEs tend to cater towards.. well, a different crowd. What that means in real world terms in often a product with rough edges, confusing patterns, and a horribly steep learning curve.

I enjoy seeing products and languages (programming) focus on learning as core feature of the product. It really is inherently important to a projects success.

It's a lost cause in this industry.

You say that, but somehow I still find the UX of every IDE I've tried to be lacking. I much prefer the UX of Emacs.

You have to realize that psychologically: you like things you're familiar with, and dislike things you're unfamiliar with. That's how top-40 radio works. That's why everybody bitches over every new software update, even when the new version is provably better.

So of course you like the thing you spent years with over the thing you tried to learn for a week and a half then gave up on because Emacs is better. That has nothing to do with UX.

In effect, a modern IDE is "programming ability" multiplier. It helps me code smarter and faster. That plus understanding what's going on behind the scenes is a powerful combination.

The difference is that IDE-like features Vim are simply tuned for C (add Lisp for Emacs) instead of Java; plugins give them support for other languages. Anyone who has tried to write something other than Java in Eclipse can attest to how much plugin creep starts to enter the fray.

IDE's and text editors overlap in their uses, but they are not the same. Sometimes you really do just have a text editing task, and none of the IDE functionality will help with it. Also, the ways in which IDE's are extensible is lacking compared to something like Emacs. Yes, they come with a bunch of built-in useful stuff, but sometimes you want to add a keybinding to do some editing task you do a lot in a particular project or company, even if it's not useful in a more general-purpose setting.

Don't know what IDE you used but Netbeans is very customisable and extensible.

I think this is true for IntelliJ and eclipse as well and it would surprise me if it wasn't for Visual Studio.

(In fact I think I have seen vim modes for all of these and even embedded vim in eclipse.)

In Emacs, adding a simple extension is simply a matter of adding a function to your .emacs file. So adding useful functionality is very low friction, low enough that you can afford to do it when it wouldn't be worth the effort in an IDE.

With that said, it's purely speculative on my part, i clearly don't know - Kakoune is new to me.

I doubt Visual Studio will be much harder.

Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.

I always use cl.exe from the command line with Makefiles.

Visual Studio can be operated pretty much entirely from the keyboard. The default shortcuts are fairly sensible, and you can always add more from the options.

There is one major omission: changing build configuration or build target. (You can give the configuration manager a keyboard shortcut, and do it that way, but it's a bit unwieldy.) So I keep the relevant widget in the toolbar and use the mouse to do it. And there are a few things I haven't bothered to assign keyboard shortcuts to, on account of how rarely I use them.

But in general, I use the keyboard to perform actions, and it doesn't feel like I use the mouse any more than I do with emacs (which I use without scrollbar, toolbar, or menu bar).

I do use the mouse a lot for moving the cursor and selecting text in both cases. (Visual Studio is actually slightly better for this, because you can Ctrl+drag to get word selection.)

Over the years I've observed that VS criticism is downvoted quite rigorously here. This is in stark contrast to the overall sentiment on the Internet, so I suspect corporate downvoting here.

The moderators should take a look at it.

Because you have to learn more commands/shortcuts than in Vim? ;)

A few hints to get reasonably good, fast:

Use ctrl+arrowleft/arrowright to jump words at a time.

Use shift to select as you move.

This works together so ctrl + shift + arrowright means select to the next word boundary.

At keast in some IDEs this will also stop at word boundaries inside a variable or function name but this should be configurable. I prefer it this way though.

Next: in the menus you'll often see a hint that tells you a direct shortkey for that menu option. This holds true for both window menus on the top as well as in the right click context menu.

Use w, W to jump words at a time.

Use v before moving to select as you move.

This works together, so vw will select to the next word boundary.

Press i to insert text, escape to stop inserting text.

Next: in the :help files, you will find a hint that tells you a direct shortcut for that command (like :help quit, or :help write, or just plain :help).

I guess my point is just that it seems to me a lot of people (not necessarily you guys) use vim as some kind of cargo cult.

If you aren't willing to learn more than the Vim shortcuts, it's unfair to criticize Visual Studio or any other product. You are the problem.

With Visual Studio, the documentation is horrible, you always encounter stale links to unorganized and regularly changing microsoft.com websites.

Relatively basic things are left unexplained and documentation is outsourced to Stackoverflow:

1) How do I restore the output window I clicked it away in order to make the editor usable in the first place?

2) What the heck is a "project" and why do I need one?

3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)?

The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go.

There are many ways, it comes down to personal preference. For example, would you prefer restoring the Output window using a keyboard or a mouse?

>"2) What the heck is a "project" and why do I need one?"

The same reason you probably use a makefile when working with Vim, to manage your dependencies and build configurations.

>"3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)?"

I don't know what you're talking about here, the debugger is accessible with hardly any effort at all. How many clicks are you using to bring it up?

>"The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go."

Depends on your use cases. I've personally never found MSDN documentation lacking, plus it's ridiculously easy to use. For example, when coding in C#, highlight a language keyword and press F1, you'll be brought to online documentation about that language feature.