As amusing as your response is, there's a pretty sharp distinction between discoverability in an IDE/GUI vs discoverability in Vim/bash. The former I can usually find the feature I'm looking for by clicking around a bit and see the keyboard shortcut for it for later use, and I can find features I didn't know existed. The latter I pretty much have to google everything that I haven't memorized

> As amusing as your response is, there's a pretty sharp distinction between discoverability in an IDE/GUI vs discoverability in Vim/bash.

I find it more time consuming to go through a bunch of menus and GUI windows to find something I'm trying to do vs being able to just run a command or Google for a command and run that instead.

Plus, for common actions with annoying to type syntax you can make a custom key bind (Vim) or alias (Bash). Then it becomes extremely easy to do once you memorize a single key bind.

> I find it more time consuming to go through a bunch of menus and GUI windows to find something I'm trying to do vs being able to just run a command or Google for a command and run that instead.

Have you ever even used a modern IDE?

I don't think I've actually clicked on a menu item in IntelliJ like, ever. Not once.

I just press "shift shift" and get the the "search everywhere" dialog which searches everything including menus and customization preferences.

> Have you ever even used a modern IDE?

Yes, I used PyCharm and RubyMine for over a year. The comment I was replying to said he was clicking around menu items to see what's available.

I don't really see a difference between using "search everywhere" vs using something like fzf with Vim (which lets you search through a ton of different things besides files).

But normally in my day to day I'm just hitting key binds or typing short commands without having to search for anything except files to open (which I could do with a sidebar instead, but I prefer fuzzy finding files based on typing out the name most of the time).

The thing is though, you have to know enough to google it in the first place. I'm sure there's a lot of users of VIM that never use certain powerful features because they don't even know they exist; that happens in an IDE too but it's a lot less frequent because a button or a panel is a lot more obvious to go "hey what's that..".

True, but you usually have at least some idea of what you want to do before you start Googling for something.

Vim's help command is also world class. It's just searching it is hard, but fzf.vim makes this easy, so you can literally type 1 word of what you want to learn more about and you'll find all sorts of results.

> how much effort people spend on learning IDE menus

I thought the point of a menu was you didn't have to learn much at all.

That's not how it actually works though. You've got what, half a dozen or more top level menus, with many submenus under those, and maybe even a third layer beneath that. And then you've got even more menus in the various subwindows anything in one of those menus might launch. Menus which again may have submenus.

And the worst part is you can't even run a text search on those menus!

> And the worst part is you can't even run a text search on those menus!

sigh

https://blog.jetbrains.com/idea/2009/06/find-action-saves-ti...

That seems like a decent alternative to menus, motivated by exactly the fault with menus I was describing: "Instead of wasting your time searching the menus and toolbars in an attempt find out that action you need right now [...]"

That feature doesn't make menus better. It makes the IDE better, by giving you a way to avoid the menus, because [sigh] menus suck.

emacs has menus too, you know.

Emacs has command lookup, too.

So does gvim, and they suck too.

I used that all the time. I rarely dig through menus. I hit Ctrl+shift+a and type in part of a command name. It makes discoverability really easy.

Isn't this effectively a more limited reimplementation of a shell?

VS Code greatly simplifies the typical nested menu mess. Also, it has a pretty good vim mode.

I just use keyboard shortcuts...

I develop exclusively in Jetbrains IDEs these days, and never let the IDE control the build. A working Gradle or Make target is required for CI/CD anyway. Our projects are officially editor independent and each contributor can use whatever they want. It is nice to click in a test and run it, but you can do that from command line too.

What I do get is correct autocomplete, documentation hinting, inline git hunk visualization, inline linter and compiler output, go-to-definition that always works and sees through implicitly satisfied interfaces, language aware refactoring tools, well designed interactive debugger, etc.

Sure you can hand assemble this stuff in Vimrc, or you can buy a tool that’s already functional.

Just one feature alone - being taken directly to compiler error sites - has saved me so much stumbling around from back when I was trying to be a shell purist.

As I’ve gotten more senior, I’ve really come around to the importance of investing in tooling (whether build or buy), having high expectations for tooling support, and having low tolerance for frustration/tedium/trickery. Not just IDEs. The right interactive debugger output, profiler trace, custom visualization, etc. easily pays for itself vs. trial and error or trying to squint at the source + output and reason about it.

> being taken directly to compiler error sites

You're in luck - this killer feature doesn't even need a plugin in vim. Just type `:make` and you'll get taken to the first build error.

> Want to customize your build?

how often do you need that though ? for me it's less than 5% of my projects which need "special handling".

"customize your build" was probably a terrible example, but how about "customize your run environment"?

I do a lot of systems stuff that can affect fs/network/etc so i have lots of scripts when developing to get everything set up pristine (I guess I use the term script to also mean Dockerfiles or helper utilities too - basically something that execs a command provided by the OS :) ). Those are modified a lot as I add features or integrations, or fix bugs, or whatnot.

That's kind of an argument for why you don't need an IDE..

Amen. IDEs are a plague. I get interviewees all the time that only know programming through the lens of an IDE. They have no idea how anything works. They consistently do worse in interviews.

I don't understand this comment. Source code is source code. The IDE doesn't write my code. What is an "IDE lens"?

I knew a guy with a heavily customized vim setup for development. He could write code without it because he was so used to his custom config. How is that any different?

>I don't understand this comment. Source code is source code. The IDE doesn't write my code. What is an "IDE lens"?

I have seen many people who have absolutely no idea how the Java compilation process works because they've never had to do it from the command line, but have interacted with it mostly through IDE tools that have abstracted almost everything away.

And when something actually breaks or is idiosyncratic enough for the IDE to not handle it, they end up very lost.

Then they have some weakness around CD/CI, I would assume. That is much worse than not knowing how to build it from the command line

Raise your hand if you've ever seen a release process that includes "Export..."?