Want to customize your build? Just drop into shell and edit your scripts. Im sure $IDE can do this too (personally I prefer just fixing the relevant script, since finding obscure features 15 layers deep in some random menu got old 15+ years ago).
You can of course run some scripts via menu when you're in IDE, and I do it when I'm IDEing of course. I just don't limit my flexibility that way, and don't know why someone would.
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.
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.
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).
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.
I thought the point of a menu was you didn't have to learn much at all.
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 feature doesn't make menus better. It makes the IDE better, by giving you a way to avoid the menus, because [sigh] menus suck.
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.
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.
how often do you need that though ? for me it's less than 5% of my projects which need "special handling".
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.
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 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.
From time to time I try to switch to IDE or another editor, but I easily get lost. I work on a big screen so I want to split my window into 2/3/4 parts to see multiple files next to each other. Vim has built in shortcuts for that and in my vimrc I added 2 lines to make custom shortcuts that are even simpler. How do I do it in Intellij? The most common way is to use mouse, which I find annoying since with Vim I'm able to use keyboard 100% of the time. There's also a way to add shortcut for that, but it's buried deep into settings (Settings -> Keymap -> Main menu -> Winddow -> Editor Tabs -> Split vertically / Split horizontally).
I guess what I'm trying to say is that what you consider "poor version of (...) functionality that comes out of the box with the most basic of IDEs" is enouh for me, and I've been coding in multiple languages over the last few years. On the other hand in other editors I have to slow down my development due to lack of good editing shortcuts or I have to invest significant amount of time into making sure that I can recreate these or similar shortcuts.
The IDE's config might be synced. If it is it probably uses a proprietary server.
You are then left with choosing between the comfort of using the subset of vim that isn't available through the plugin, and the comfort of using all the IDE features that aren't available in vim. I believe that for most people the latter will be far more productive.
In those 3 years I spent 3-5 hours in total configuring my .vimrc to make it work exactly as I want.
I can compare directly my productivity using Vim and other IDEs and I'm like 50% more productive using Vim.
I'm not sure how this criticism applies to the post; it's a single plugin that adds language-server capabilities that almost every IDE is using today.
> Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin.
Alternatively, if you use vim, you can just as easily download the popular rust.vim plugin which was written specifically for vim by the rust development team.
poor versions of that comes out of the box with the most basic of IDEs.
The functionality isn't "poor" or in "narrow slices"; with few exceptions Vim is fully capable in terms of IDE features and actually exceeds what is possible with most IDEs individually. Products like the IntelliJ suite of editors will always have more "out of the box" features because their business model is selling IDEs with lots of features. IMO the vanilla editor + plugin model is superior because it allows you to select your features a la carte as they make sense for your workflow rather than being thrown into a bundle of different features, many of which you don't need and most of which you'll never use. With Vim, every feature is deliberate and the experience can be super lightweight or relatively heavy, but ultimately customizable to the point of perfection. Of course, tweaking Vim to be your perfect IDE takes time, but that's the tradeoff for a self-tailored experience vs one that was designed for you based on someone else's ideal workflow. There's nothing wrong with just picking something off the shelf and learning it, but some people want to optimize their workflow and most people end up switching IDEs over time anyway, so I think the idea that you can simply learn one thing and use it forever isn't typical.
> I just don't write code that way and don't know why someone would.
I prefer it because its fast, clean, open source all-the-way-down, and I can manage and access my entire development environment remotely from any machine, with full fidelity and capabilities. Tty applications also combine beautifully with tmux allowing me to arrange my editor into tight visual coordination with other commonly related tasks that are specific to the context of the files i'm editing (e.g. tailing logs, running binaries/scripts, copying/moving files). Additionally, tty applications tend to integrate very well with eachother since the designers tend to have an appreciation for the the unix philosophy.
Is it really "just as easy"? The last time I tried to install plugins for Vim it was not easy. Vim doesn't have a plug-in manager built in while VS Code, in this case, does, and it's 2 clicks to install and restart.
I would consider vim more customizable but I would not consider it "easier".
It's dead simple. No, it doesn't come out of the box, but it takes literally 5 minutes to install a plugin manager and you only have to do it once; afterwards, installing, updating or removing plugins takes literally seconds.
I believe it's easier to start with one of existing Vim configurations like Janus[0] or spf13-vim[1]. I tried a couple of such frameworks and they helped me a lot. They come with set of packages for navigation, fuzzy finding, as well as with some package manager. They're also quite easy to install.
[0] - https://github.com/carlhuda/janus/ [1] - https://github.com/spf13/spf13-vim
Easy to add new plugins, update and so on. And it’s usually just download one file to make it work.
I think that it's the other way around: people don't want to lose the editing experience that they already have by switching to another environment that might have some other benefits. For some people, that means an environment that they've tuned to their own requirements over years, and for others, it's just the core interaction model.
For me, I like modal editing, and the Vim commands are now automatic, but I have no attachment to any implementation of these, so I use the stock Vim on CLI, and VS Code with the Vim extension everywhere else to get modern features without losing the aspects of Vim that I really care about.
I mean what is the point of this comment if you don't know? What comparative warrant is there to even discuss? Having attempted to move to Sublime, Atom, VS Code with their respective Vim extensions is _not_ the same thing if you understand how to vim, so mucking around in your respective $GUI_EDITOR's Vim mode is never going to be a symmetrical experience, not even in a "good enough" way cause you always end butting up against the inherent design of the $GUI_EDITOR. It's true that vimscript, package management, etc could stand to be given a second look, but those things aren't showstoppers and have no bearing on the central value proposition.
I'm also wondering when the last time you've used Vim was, because async plugin execution is now a thing, but I switched to NeoVim a while back it's fast.
My vimrc is at: https://github.com/nickjj/dotfiles/blob/master/.vimrc
At work, on OSX, VSCode has been fine though. Still, I've never run into a situation where nvim is slower. And I use a good many plugins (deoplete, ALE, ctrlp, fzf, and 5 sets of language specific plugins).
I work mostly in ruby and the vim ruby experience is great. I have spent a year watching coworkers work in RubyMine and there isn't much it provides that I can't do (literally) just as well in vim. In fact the navigation tools are superior in vim as far as I'm concerned. RubyMine does have better project wide refactoring support, but with ruby being a dynamic language, you still have to go and check every file that changed to make sure it did the right thing anyway.
The uninitiated always stumble around with vim like bumbling bafoons wondering why anyone would use something so antiquated, but in the right hands vim becomes an elegant weapon for coding at the speed of thought.
A pity that for want of a GUI, most will never feel the power.
I use VS Code sometimes, and got it configured to run unit tests on live code and constantly report on passing, and then I went back to vim. I don't need a herd of assistants begging for my attention, and it hurts my productivity.
I tried looking into Vim / NeoVim a few times to understand what all the hype was about.
I had to install:
* Fugitive * Nerd tree * Airline * YouCompleteMe * Emmet
And I don't remember how many other plugins just to get a halfway decent editor experience. I get using Vim if you're SSHed to a server, but otherwise it feels like intentionally handicapping yourself. In case you find yourself needing keyboard based navigation, I'm pretty sure Command+P is much better than anything Vim could offer for quickly opening files, and there's a Vim plugin for VSCode for moving around in files.
I will probably get heavily downvoted for saying this, I know. But if someone feels like enlightening me instead, please do so.
If you're used to IDE's it's doubtful you'll appreciate vim by "trying it out" for a weekend. The learning curve is much too steep for that. Conversely, if you've used vim and terminal tools on a daily basis for >15 years, you probably won't have much motivation to switch to GUI-based IDEs.
I've been using (Neo)Vim for a couple years now and only regularly use 6 plugins that actually do something, and 2 additional ones for the eyecandy. All the rest is just a matter of knowing the features that already come in Vim, and efficient keybindings for them.
Also, Vim isn't something where you can just jump in for a test drive. You never stop learning Vim and it takes time. But once you get hooked you won't use any other editor without a Vim plugin, no matter where you end up eventually.
That being said I have spent tens of hours trying to get everything just right in Spacemacs.. and some things dont work still.
if this is possible... please teach me! i searched online and only found articles about enabling basic vim keybindings and gave up after that tbh.
But yeah, airline is mostly just eyecandy.
Is vim really getting hyped anywhere? If so that must be one of the longest running hype trains in tech.
* A new language or paradigm comes out
* Clicky tool makers (IDE, management software, etc) can't really keep up with the rapid change, and they aren't sure if this will catch on, so they don't make great tools for it. People have to use the cli tools to take advantage of all the features.
* Since folks are already in the shell, they want to make their environment better, so new folks are introduced to shell stack, and new customization options for tmux or shell or vim come out.
* Eventually if the thing catches on Clicky tool makers catch up and the shell scene quiets down a bit - people abandon shell stack for clicky tools if that's their preference, and the new shell converts integrate with the broader "shell folks community". (That community is always there, just quietly using the relatively stable interfaces in the background).
* At some point a new language or paradigm comes out...
Actually, you're wrong here: https://github.com/kien/ctrlp.vim.
https://github.com/junegunn/fzf.vim
Fzf is an incredible fuzzy finder, integrates into your shell really well (history search is brilliant) and the wrapper in vim is lightning fast.
Ctrl+P inside of VSCode is way way way slower than fzf with Vim. Even Ctrl+P with VSCode on a small amount of files had some amount of lag on it but fzf and Vim is nearly instant with thousands of files. There's also a lot of great fzf related shortcuts with Vim too, like being able to search more than 1 file with ripgrep or searching through lines in a file, etc.. All of which are super fast operations. I can search through a 900,000+ word markdown file (over 100,000+ lines) in Vim instantly with fzf's line searching tool.
It's a good thing somebody put the effort into the Rust plugin for IntelliJ CE. When I started writing Rust, I used vim with syntax highlighting, so I guess I might be part of the reason Rust became popular enough to get IDE plugins. You're welcome.
Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin. I'm sure VSCode can do this too (personally I prefer Jetbrains products and have been using them for 15+ years).
You can of course use a tty-based text editor over an ssh connection and I use that for Linux servers I connect to of course. I just don't write code that way and don't know why someone would.