Yes, there's an official IdeaVim plugin [1]. I'm not sure how deep the rabbit hole goes, I just use it for basic vim goodness, and shy away from advanced stuff. But sure, modal editing, movements, macros, search, etc, are all there.
There is a (or more than one?) Vim plugin with fairly good support. However, it is not Vim. Most of the common Vim operations work but others are broken.
For example, I've found the weirdest bugs when using visual block, especially in column mode. It just completely mangles everything.
I switched from vim to Webstorm, which is based on IntelliJ. I agree with most of this article. IdeaVim is a pretty good vim emulator (although not perfect, but none of them are).
There's something to be said by having sane defaults that do exactly what you want. Probably my biggest issue with vim is you can easily find yourself in no man's land because your setup inevitably becomes uniquely your own. For example I used coc.nvim in vim, and although it worked great overall, I would often find autocomplete text sitting in an unnamed buffer that I would have to clean up. Despite googling like crazy and even asking for help in a couple vim communities, I could not solve this problem that seemingly only I had.
The article touches upon this as well, saying a 50 line tsx file doesn't work for the author in vim. For me a 1000 line tsx file works just fine, so the author managed to dig a unique hole for themselves there too, most likely.
Totally agree with your point. Tools that allow great personalization are obviously more prone to generate weird problems unless you know what you're doing™.
Or to quote a famous philosopher "With great power comes great responsibility".
I keep hearing statements like this and I want to believe. I really, really do. I see the value in Emacs Lisp vs. vimscript immediately, though I feel that Lua in neovim is making up ground there.
I've tried evil-mode a few times over the years. Most recently I tried Doom Emacs twice. I _really_ want to experience the hype of org-mode. I want something like org-mode in my life. I am a heavy notes taker and I can see the value org-mode offers and I am willing to make the jump for it alone... But, I can't figure out how to get a proper workflow in Emacs that gets me to where I am in vim today. I just can't get it to click.
For what it's worth, I've been using vi(m) since the early/mid 2000s and my workflow is almost entirely terminal based for almost everything that I have ever done as a professional and hobbyist programmer. To the point that I feel like I cannot be as productive in ecosystems that are GUI based.
I started using Vim in mid/late 2000s, and successfully switched to Emacs. Without knowing your specific gripes, it's hard no know what'll end up helping you, but here are my two cents:
- use emacsclient and have aliases for emacsclient -c and and emacsclient -n for popping up a new frame or using the console, respectively. I even have a window manager binding to open a new Emacs client window
- Rainer König is the best at getting across org mode workflows. if you like watching nerdy videos, go watch him.
- keep vim around, I still use it, sometimes, but with no or veery minimal config.
- centaur tabs and the new tab stuff can help vim people who like tabs. I just got used to buffers.
- M-x is really Emacs' primary UI. don't try to think of a million and one key bindings up front, just bind what you find yourself using M-x a lot for. You just need a nice completing read like ivy, helm or so, but doom has that.
- use magit. While many claim that org-mode is the Emacs killer feature, I'd say magit is even more important if you code. There simply is no better git interface, nothing comes close. You think git the new porcelain is cool? Magit is a git jacuzzi.
Thank you for this list, I appreciate the effort. I've got some time off of work next week and the kids won't be home, so I'll spend the day digging into this.
To add onto this - I'm a huge org-mode user. If you're on iOS I highly recommend BeOrg[1]. It's the best org-mode app for iphones. It's highly extensible on it's own since you can put in settings and run scheme in a config file[2].
You can purchase extensions for it which are all pretty cheap. You can also pay for a membership to get all extensions - this costs only $10 a year.
The creator of the app is very active in the forums and is constantly updating and improving the app. I love it and it has made my usage of org-mode on the go much easier.
I'd like to add: org-mode is overwhelming, so just take it easy. Set up a notes folder, sync it to the web, and just use org as a plain markdown/todo list editor for a while. Perhaps add org-roam (like vimwiki with backlinks). Then, only if you feel the need to, give org-capture and/or the calendar/agenda features a try. Don't force yourself to use some obscure feature just because it's there in the manual on page 587, or because you saw someone on Youtube rave about it.
I switched to Doom Emacs about two years ago and while I miss the insane performance and simplicity of vim sometimes, the positives overall outweigh the negatives once you get over the initial differences (workspaces, command names, etc.).
I absolutely love magit. I tried using to emacs as my main development tool but couldn't be bothered to learn a proper workflow yet. I also tried learning org mode but I have no use case for it yet. But magit is just the best frontend for git.
I spent quite a bit of time with vimwiki Saturday and today. I really like it. I already stored most of my digital notes in plaintext files so this is a really nice migration path for me. Thanks a lot for the advice!
I used to use Evil mode and now I use God-mode[1].
Evil is great, but you end up having to know Vim keybindings and some Emacs keybindings since Evil doesn't cover everything.
It certainly can with additional Evil extensions and modifying your .emacs, but I still felt like there were some parts of Emacs where I needed to know Emacs key bindings.
God-mode works since it just makes it so that you can use Emacs keybindings without modifier keys. Everything works out of the box. Best part is that you can install extensions without needing to come up with Evil keybindings for them.
Is it possible to do inoremap jk <ESC> yet in Evil? That's a huge optimization for a really large minority of Vim users and without that, Evil definitely isn't Vim's equal.
Have you taken a look at Evil-Escape[0]? I've bound the keys to "fd", because that feels natural, but it's trivial to do "jk". This package works on much more than just insert/normal mode switching as well.
I've recently been picking up Emacs for org-mode. Evil does not support settings such as `:set nu` or a thousand other settings that I use once in a blue moon but expect to just work. Even `:wq` attempts to close all buffers, `:e` doesn't open files as expected, I could go on.
IdeaVIM get 90% of VIM right, and some things wrong (such as `u` for undo also undoing movements). Evil gets 95% of VIM right. But I have high hopes for NeoVIM allowing an actual first-class VIM implementation to be embedded, not copied, into an IDE or even Emacs.
For me, `:wq` saves the current file and attempts to close all buffers, though thankfully asks if other unsaved buffers should be saved before closing.
I was wrong about `:e`, it does work.
Instead of `:set nu` I'm using Alt-X UpArrow+ to find `display-line-numbers-mode`, which does what it says. But there are other settings which I have on muscle memory macro that do not work, such as `:set wrap!` which I use often with my portrait monitor.
Yes, I was specifically talking about copying things to and from vim, with/without tmux. Maybe its not a huge issue to all, but I always forget when I set things up on a linux machine vs. Mac OSX
gvim on mac/linux/windows will use the + register for the system clipboard. I'm pretty sure that a terminal vim with gui support compiled in will do the same (I know it does on Linux/X but haven't tested on mac or windows in a while).
This is true, but often terminal vims don't have clipboard support. For example the vim that is bundled with Ubuntu does not. This can be especially confusing for people new to vim, or sometimes you jump onto a random machine and find that "+y does not work.
I guess that's another thing to add to my list of "reasons Ubuntu is terrible" it's a minor complaint, but good to know.
[edit]
FWIW, "gvim -v" will probably give you clipboard support in a terminal on ubuntu, and ubuntu might have an "alternatives" tool to make the "vim" in your path have X support. "The Ubuntu packager compiled vim with the feature I want disabled" is a poor argument against vim; it would be like someone saying "I switched away from vim because I wanted to write plugins in Python" just because the packaged version of vim they use has python integration disabled.
I've found it to be a colossal pain in the ass in WSL, since the emulated linux clipboard isn't synced with the windows clipboard. I have to :wq, cat the file, and ctrl-ins to copy.
I'm not sure about the specific instance of vscode. Since it's a gui app, I don't think you can run it inside of wsl. You can use a plugin to connect to wsl, but I don't think that's quite the same thing, and I wouldn't expect it would allow clipboard sharing.
The general point is right though. This is an issue with any terminal program that either doesn't allow selection of text, or has a system for selection of text that's separate to that of the terminal emulator.
If you set up VcXsrv (an X-server) then your clipboard will be shared between WSL and Windows and Vim will work as long as you have +clipboard support in your copy of Vim without doing anything extra.
I've never been able to get netrw to work when mixing Windows and Linux machines and that's the environment I work in. Plus, I usually need to do more than just edit some file and so I rely on screen.
As an aside, I just tested it and "+y and "+p work fine with vim over ssh if you enable X11 forwarding. Apparently you may need to use "gvim -v" rather than "vim" on Ubuntu though.
Agree with the article. I love Vim, but mostly use webstorm for the same reasons.
I just find all jetbrains products run like molasses, even with a 12-core machine with 32GB ram. I work fairly quick, and get frustrated when my editor holds me up.
Surprised to hear about the crashing issues with typescript, but I don't have any experience there.
AppCode is way snappier for me than Kotlin-in-IDEA. AppCode is also more likely to shit the bed and not be able to find a standard library class with ctrl-click.
"Switching" seems like a strong reaction, but there's something to the feeling the author describes.
I use vim quite a lot, every day. I also use IntelliJ IDEA every day. And yes, there's a bit of mental switching I do, and every now and then I use vim navigation keys while in IDEA, but generally it works for me. Different tools for different jobs.
Then again, I have no trouble loading reasonably large documents in vim, so maybe I don't have mine quite as customized as the author.
BUT I relate to the feeling of not being quite sure that all of my customization are quite enough, of not using vim to its full potential. Or even 10% of its potential.
I'm the same way. The wires don't really seem to ever get crossed for me. When I'm using intelliJ, I honestly find that I'm not really typing all that much. I'm either reading/navigating code (and therefore ctrl-clicking on identifiers or using shortcuts for finding usages etc), or typing in a pretty linear fashion that is the sort of thing I'd be in insert mode for the entire block anyway. So when I spend most of my time navigating/reading, it feels really good to have a robust first-class experience with the relevant features in your chosen environment. I know vim can do all that stuff, but it's all tacked on and never (IME) doesn't feel tasked on. Whereas the IDE understands the semantics (the AST) in a way that vim/ctags likely never will.
Some of this is particularly strong due to the language I use most - Java - where the IDE is nearly bulletproof in terms of finding exactly, only, and all real usages of identifiers (it won't ever get confused by two different identifiers with the same name) which isn't true for pycharm/python (though it does a good job honestly, but you can't blindly trust it like you can with intelliJ). I could see how someone would find pycharm not quite as much of a win over ctags, though IMO it still is.
[edit] That said, I still use vim quite a lot. I wouldn't use anything else for editing config files or just examining text content. Especially since you can pipe to it - seldom a day goes by when I don't "| vim -" instead of less or anything else.
> BUT I relate to the feeling of not being quite sure that all of my customization are quite enough, of not using vim to its full potential. Or even 10% of its potential.
There's a lot of built-in features in vim without requiring the installation of plugins. So, you might not need to customize it at all to use more of its potential, just read the manual.
vim is just a set of well-thought key bindings and commands. JetBrains built highly successful business on providing "working from the box" IDEs.
Not to mention vim's buffer concepts, entirely different from usual tabs.
Article literally goes "I tried to build ultimate IDE from vim, sometimes it's good, sometimes not, but then I discovered this not that free tool called IDEA and damn it works".
I made a similar switch and now use CLion instead of pure vim.
For a long time I thought I would miss vim editing experience but IdeaVim is the best vim emulation plugin I've ever seen and I hardly can remember a vim feature that is missing in IdeaVim.
Though I have to accept occasional UI freezes and huge memory consumption of CLion.
The amount of different completion plugins in Vim is something that I also suffered a bit. I tried many of them (YouCompleteMe, Deoplete, Coc.nvim) but none of them really worked properly.
For the moment I mostly code in Python and I settled with a very minimal setup:
1. Linting: python-mode. IMHO it provides very good linting out of the box
2. Completion: jedi-vim. Jedi for python is great. Even though with this minimal setup the completion is not asynchronous I still think it's great.
It took me some time and a recent pruning to actually arrive at this minimal setup. I totally feel it with the author that finding the right set of plugins in Vim can be a bit overwhelming.
I recently switched from IntelliJ IDEA Ultimate to VS Code for Go development (side project), because I don't want to pay for it, when I'm no longer a student. With Golang VS Code works great after getting used to it. The Go plugin is not available for the community edition. For Java and Android development I always used (and still use) IDEA because it's feels much better than Eclipse.
While an OK option if you're optimizing only for money spent on tools, I would still say this is not a good idea. There are bugs and depending on your workflow can be pretty dramatic show stoppers. Value your time more, upgrade when you need new features/solving a problem but otherwise I think stability in your tooling is very valuable.
I pay for pycharm and still used EAP releases for a year without encountering stability issues. I turned EAP off only because it kept breaking my plugins.
I went the other way around (from VS Code to IntelliJ), it has some refactoring support and the like, and I have to work and switch between a few languages during an average work day. VS Code is fine for a lot of things, but not as powerful as intellij.
That said, main downside to IntelliJ is IMO speed and input lag in editor windows, mainly in TSX files. I admit it's a complex language and the fact that Prettier runs on save probably isn't helping either, but still. It has trouble resolving imports, some are done automatically, others you have to select a quick fix options for, and sometimes both work and you end up with the import itself getting munged.
Interesting my frustration with VSCode (for typescript) was that everything felt sluggish compared to Idea. I guess that may be something where hardware configuration and organization of project matter?
VS Code for Go is really good, your move makes total sense.
I was a happy VS Code user (after being a happy VIM user for a while) until I switched jobs from Go codebase to Ruby and then I quickly jumped back to IntelliJ. So far (for me) this is the only editor that correctly figures out most of the definitions and locations of methods/classes/etc.
Intellij IDEA is my go-to tool when working with the dynamic beast Ruby.
Well, actually Intellij IDEA is my overall go-to tool, also now when I work with Go again mostly.
If you plan to be a professional software engineer, then I recommend just paying for the best tools. The price of one hour of an engineer's salary (give or take) can pay for the entire IntelliJ suite for a year.
And you don't need to continue your subscription unless you want continued updates. My PyCharm 'subscription' lapsed around two years ago, and I'm only planning on purchasing a new fallback license for the upcoming 2020.3 release because their excellent vim-mode plugin finally supports jump lists, but requires a newer version than the one I originally paid for - and I'm honestly happy to pay them again.
And they allow one to use the personal license at work, so long as no one at home is simultaneously using that license (I'm paraphrasing, and also cognizant that "at work" and "at home" now mean something radically different than this time last year) : https://sales.jetbrains.com/hc/en-gb/articles/207240855-Can-... (going up one level has all kind of interesting other licensing FAQs)
I actually still do that even though work bought me an IJ license because my personal _suite_ license covers more tools
The definition of "best" is often subjective and may boil down to familiarity.
On the other hand, betting on open-source tooling may be a good way to increase the chances that your "best" tools will still be available in the future.
I've been using JetBrains tools since 2004/2005, and I've become so attached at the hip to IDEA, CLion, etc. that it has become hard for me to work in anything else. And it's really bitten me recently because the codebase I work in (C++, Chromium based) just won't index in CLion, it's so massive that CLion just pukes. That and with my remote work situation I'm really down to mostly using CLI tools, so it's back to Emacs (which I like, and have made work for me, but it's ... not the same)
I fear someday having to do job interviews and having to get up on a whiteboard or use some half-assed shared-coding IDE, because my fingers and eyes, they really want JetBrains products there... I don't type out for-loops, I use generators, etc. etc. it's all so much faster...
As a long-term Emacs user, I started really enjoying typing with Vim bindings (evil mode).
It feels to me that Vim is great at the low-level process of editing text. Everything else is fine - as good as any power editor, but not inherently great. This is the complement of Emacs, which to me is exactly the other way around.
I've tried evil mode a couple times over the years, but slight behavioral differences threw me off my game. I don't remember exactly (it was years ago on the last attempt), but it was something small like the cursor position being slightly different after some operation like shifting a line.
My "problem" is that since I've been using the same editor for 30 years, I don't tend to think too much about the manipulation of text. So even the tiniest of behavior changes is unsettling to me.
Though I could probably adapt.
I should try it all again (maybe not emacs, but something), and really set up everything well for auto-complete and such (mainly C and Rust). My current vim setup (using pathogen) is sort of a mess.
for me, the basic keybindings are what matter. I use a full fledged ide, but still have vim bindings. When you become comfortable enough, editing becomes quicker and more in line with my train of thought. Thought->action->code change becomes very quick
For me, a killer feature of evil-mode is the "hybrid" state (`evil-disable-insert-state-bindings`) that allows to use emacs (aka readline) keybindings in insert mode.
When I have only a minor edit to make in the middle of typing something (like transposing two characters) it saves me the back-and-forth with the normal mode and it's really sweet.
It probably makes me an heretical freak, but I'm definitely hooked. I guess I am condemned to live the rest of my life in emacs now.
I want to switch to using Spacemacs and use Evil but on Windows 10 I'm having no luck getting that working due to some weird errors when emacs starts and tries to install the packages. So for the time being I'm stuck using vim.
I confirm that, switched from an overly complex config to spacemacs then a year later to doom. Doom feels much more polished, faster and require a lot less configuration, at least for my use case.
Sounds like the errors I got installing spacemacs. I think... I forced it to work by changing the access permissions on a folder that spacemacs itself had created.
Portacle worked really well for me on Windows 10, while learning Common Lisp. It's a nice base of settings that can be esiliy expanded upon. Vanilla Emacs was a nightmare. Once I got comfortable with Portacle, I swapped out the emacs folder with the a v28 build for much better performance. Much better than Space/Doom Emacs (on Windows).
I'm still holding out for proper IDEs with embedded neovim at the core. Vim has a few killer apps I can't live without - custom text objects, vim-surround, and vim-sneak.
vscode has that, basically connects to a background neovim instance. I use the same vimrc (with minor tweaks for easymotion) for both neovim in cli and in vscode. Although at work I'm still using webstorm with the vim emulator
Yeah, I've been following that one for a while, I pre-ordered it. I was a little disappointed they switched from neovim back to vim. I'm sure the engineering reasons were sound, although I didn't understand them and it made me a little less excited about the project.
Not sure how to feel about the goal of vscode plugin compatibility. I'd hope for a vim based ide to kind of "be its own thing".
Why do you prefer neovim to vim? I tried both and as of vim8 there wasn't anything keeping me on neovim so I switched back. I figured any neovim features would be handled by the IDE side
- Moving away from config and plugins in VimL, which is extremely idiosyncratic and awkward to use, towards lua and other languages via rpc
- Long term health of the project - neovim feels like a truly community driven project, whereas Vim seems bottlenecked by Bram and his specific desires. Neovim has also gone to great lengths to make the source easy to maintain long term.
I was thinking there might be something interesting here. Then I got to this line:
"I started a new job working on a large typescript React project. Vim couldn’t handle opening a TSX file larger than 50 lines without crashing."
And I was like LOL WUT? The author's case in this regard woudl be stronger if they helped us understand what was actually going wrong. Bad plugins? Conflicting macros? I'm pretty sure that simply opening a 50 line TSX file does not normally crash vim.
Well, the thing about Vim and Emacs is that the users are expected to figure out configuration problems like these. That's not a point in favor of Vim and Emacs.
Exactly. If you argue the pros of vim/emacs using the power that comes with access to extensibility functionalities, it seems intellectually hishonest to not consider the ecosystem and customization issues also for the cons.
Well, some mixed feelings on whether or not it's a point in favor or not. Just like any system, don't install plugins/copy+paste config that you don't understand or can't maintain. I've been able to open tsx files with linting/highlighting/testing plugins and everything works as expected.
On the flip side, if you want easy configuration, then yes, vim/emacs/similar are not necessarily the right choices for you, but I don't think that means they are generally bad options.
> Just like any system, don't install plugins/copy+paste config that you don't understand or can't maintain.
I don't think this advice makes sense at all. I can't maintain cc-mode and I don't understand how it works, yet I rely on it.
Users should not be expected to understand how the TypeScript autocompletion works in order to get it working. I can open VS Code on a TypeScript project and get autocompletion working just based on the tsconfig.json, much of the time.
I guess it really depends on where you want to spend your time. Time spent customising and tweaking my tooling is time not spent focusing on my core work.
Hence why, despite my interest in Fish, I'm still just making do with Bash, I just can't justify the time to make a proper switch.
Note that you can still use <favoritesmalleditor> for those big files and the IDE for all the rest. I am using emacs with IntelliJ Idea (one shortcut or action to open current file or selected file in the file list if you don't want to open
it in IntelliJ) . I'm using that when I need to edit orgmode files or do complex text processing on a file.
Right, The point was about configuration. I had a configuration that worked for a couple years, then I start a new job and the config breaks on the first 50+ line TSX file. Now I have to go and find the culprit, find a replacement plugin (in this case, yajs JS parser was slowing things down). and before I knew it, I was re-configuring everything again. I was more criticizing the ecosystem of plugins and how brittle some may be.
That's definitely a huge issue. I've had the same experience of having to spend hours to a day getting my configuration set up for a new language. I think part of the problem is that there's no basic config for a language (as with other editors) from which users can tweak, mostly because anyone who tried to get vim users to standardize on any defaults other than those shipping with vim itself would be strung up and horse-whipped as a purveyor of bloat. Vim is a great editor and I love using it, but many community members have a "leet" attitude that discourages new users who need help.
It would be a whole lot easier if someone put together a set of basic configs for various languages that had language servers, completion, etc. and everyone referred new people to those. It's much easier to tweak and replace stuff than to assemble an entire config wholesale.
Yep, I too have switched to it and pair it with CCLS for my C/C++ development. It works great after learning it and does significantly reduce the overhead needed for new languages. It's a little tricky to set up for new users, but it's nice that things have improved so much.
I don't really care how good emacs or vim are for text editing, I always crave a good IDE as text editing is just a small part of writing code. It may be because I'm using java/kotlin, and the stuff a good IDE can do there is much more than in some other languages. But the refactoring, find usages, debugging, building, etc is just so smooth and integrated I've become an IntelliJ fanboy.
Refactoring tools do more harm than good and they exist to duct tape the complexity path some programming languages set you on by adding more complexity.
That's... an interesting take. I'm not sure it's well founded, could you expand on your thought?
The refactoring tools in JetBrains products are amazing for me. Renaming a variable and having all uses within scopes renamed too is great. Renaming classes by patterns is also great. Being able to move definitions to new files and have it update all my imports etc is great.
I mean, Java is pretty notorious for sprawling names like INetworkSessionManagerFactorySidecarControllerFactoryHelper. It's pretty hard to argue that that phenomenon isn't driven by the ubiquity of IDEs in the Java community.
With high-powered auto-completion and one-button refactoring, your brain stops processing the full name. No one's incentive to pause for a minute and come up with thoughtful variable names. For most developers it's too mentally tempting to just puke out some CamelCase word salad, because the IDE hides all the effort of having to read/write/remember unfortunate names.
That's a valid complaint, but at the same time it's not always easy to come up with a good name from the start. I often find myself putting in placeholder names for variables/functions because I'm really not sure what it's going to encompass by the time everything is finished.
IDE refactoring makes it easy to clean up names after spending some time with the feature and better understanding what the scope of each function is going to be.
It's great to pause and come up with meaningful names and I agree more developers should do it, but refactoring is a normal part of coding and I'd rather have an easy way of renaming things as the code evolves.
Somebody who is too lazy to choose a good variable name in IntelliJ would also have chosen a bad (or even worse) variable name without the tooling. I don't buy that argument.
For class names it might be true that long compound names are driven by auto suggestions from the IDE. But I'm wondering if they're really as bad as their reputation. Somehow it's similar as for variables. You can still come up with more meaningful names if you want but I admit that auto suggestions do more harm there.
I think the parent post was attributing longFuglyCapsUnpronouncabeName type identifiers to the Java language/culture, As much as (just) the editor?
I’m biased, though. I HATE gigantic supposedly “self documenting” (but utterly impossible to actually say aloud) identifiers.
My ideal identifiers are 2, maybe 3, syllables, with dashes or underscores, with actual documentation of WHY anything visible beyond The scope of a single function is used.
I guess any piece of code will have someone who finds it horrifying. I prefer long, self documenting identifiers over short (often misleading) ones any time.
Sure IDEA is primarily aimed at the JVM market, but I use IDEA's refactorings in Python, Go, Bash etc.
And I'm unsure about your point about meaningful names - IDEA typically won't suggest a name when renaming an existing language artifact - type, class, object, method, function etc.
It will when extracting an expression into a variable, based on the context it was derived from, and that's actually a pretty good heuristic - e.g., if the expression being extracted is
<some_var> = dependency.get_campaign_results()
It'll suggest things like
campaign_results
campaigns
results
Most of which are what a developer would usually use in that situation.
How often do people rename identifiers for that to be a particularly useful feature? If it's not that often, you might be served fine with something like
sed -i 's/foo/bar/g' **.rb
It's not precise, so it might take some manual work and tweaking with the patterns, but for how often I've had to rename identifiers, it works good enough to handle the bulk work.
A bit of forethought when first naming things works wonders, too.
Refactoring is an essential part of software development.
sed is not gonna cut it. The same way that inserting a newline character every 80 or so characters cannot be called source code formatting
Refactoring doesn't consist only of renaming identifiers, and for the portion that it does, regular vim features like `/`, `c`, `n`, and `.` or macros or such are often enough.
That only works if the identifier name is unique across your files. What if you have a field on class "Zoo" named "containers" and you want to replace it with "animal_containers", but only for the "Zoo" class? There are probably other usages of "containers" in the code, with no easy way for something like sed to distinguish between "zoo_instance.containers" and "car_instance.containers".
You need an editor that can understand "this usage of 'containers' refers only to class 'Zoo', so I should find all variables of type 'Zoo' which reference the 'containers' field and change those."
> That only works if the identifier name is unique across your files
hence
> It's not precise, so it might take some manual work and tweaking with the patterns
and like I said,
> for how often I've had to rename identifiers, it works good enough to handle the bulk work.
so
> You need an editor that can understand
No I don't, because renaming across many files is rare enough that I don't need it.
Most of the time, I do refactoring before it's gotten out of hand and so regular vim features like I mentioned in another comment are typically enough.
In other words, I think such understanding by the editor is too much complexity (and language-constrained, at that) for little reward.
So much so, that I suspect a lot of programming languages not see wider adaptation because of crude tooling. What good does it make to have advanced language features when the development experience is subpar?
I would suspect if a language advertises it has superior reasoning capabilities about code that should also enable a superior IDE experience as well. Where are those IDEs?
It's worth noting that the IntelliJ IDEA Java IDE was Jetbrains' first and it is written in Java. A few years later they invented Kotlin with a focus on strong IDE support. The language was designed from the beginning with tooling in mind.
I have been using Jetbrains IDEs for a long time now, started with PyCharm and made my way through Webstorm to CLion for uni. It's great, but the RAM cost has been too high for me.
I've been slightly switching the opposite way, using vim more and more for smaller stuff and opening the IDE only for larger projects or work stretches. I definitely love the value of vim as a nifty tool, my workflow is noticeably faster.
As an aside, that cheeky :wq is not missed by me at all, :x all the way!
As for ram usage, I currently have two huge java projects open, and three elm/frontend projects with all the shared packages opened as modules, and it's about 5GB. While it's certainly more than a text editor (still less than chrome lol), is it really so bad? My laptop got 64GB of ram and 34GB of those are sitting unused and 8GB is just cache. I actually prefer it to use more ram than having to recompute stuff or load from disk.
The computer I bought as a "poor" (western) student in 2012 had 16 GB ram. I can't really see any professionals stuck with 8 GB ram nowadays. As I said, even Chrome will kill a computer with that amount.
So I can see it being an issue, I just think an IDE isn't optimized for that kind of usage, I guess? I acknowledge I'm speaking from privilege here, though, and that probably non-professional users would like to use this software as well.
Fair—I think this ties into a difference into the ubiquity of powerful systems and internet in the west. For example, up until not too long ago, I could not just blindly afford to have a 2GB visual studio toolset downloading in the background for rust without completely blocking the wifi. In general though, that size is literally peanuts.
For what it's worth, I just took a glance at required PyCharm specs.¹ They recommend 8GB and minimum 2GB ram, which seems a bit dumbed down. I can't imagine anyone being able to properly run it without at least 4 gigs of ram even if they have nothing else running.
Agreed, as Vim/Neovim has risen in popularity recently it seems there is a trend of people thinking it’s only usable if you install these 57 plugins, and a large number of these users seem to have blind spots on Vim’s native capability.
The autocomplete feature is a great example of this. I do not use an autocomplete plugin at all, but rather use Vim’s native ins-completion. Combined with a language server and a lightweight LSP client (I use vim-lsc) this works beautifully.
I am excited for some of the upcoming changes in neovim however. I think the introduction of treesitter for syntax highlighting and a native LSP client will both be huge
I've checked out a build of neovim, and the native LSP is rudimentary but even in that form, very slick.
I am often torn with the same conundrum - I've been using neovim for Ocaml, and I really just like vim as an editor, but having inline linting is really really nice. But it's also really, really complex to configure, and it detracts from why I love vim so much - if I wanted an IDE, I'd be doing my Scala work over in Intellij.
I'm still contemplating whether I can get what I want with a second window a file watcher running build commands.
I switch from Vim to IntelliJ and then back multiple times every day - one is for fast editing of smaller codebases and the other is for sprawling codebases. One thing I've noticed about IntelliJ though (and any other IDE), is that eventually I manage to get the thing configured into some inconsistent state that I can't figure out how to get out of and I have to restart everything from scratch before I can get things working again - up to and including deleting the entire IDE and reinstalling it. The bad thing about command-line editing is that it doesn't do any magic for you. The nice thing is that it doesn't do any magic to you.
Every few weeks I get my (vscode) IDE into a state where it no longer autocompleted and I have to reinstall it.
Have yet to encounter the problem with emacs
I have my intellij idea pretty exhaustively customized for years and i have never had any of these issues described here. you might need to be careful about which plugins you're using.
Little off topic, but it unfortunate that the ultimate edition doesn’t include C/C++ and I have to buy yet another pack of “all products” to get that. I pay out of pocket and have yearly subscription. Not sure if the next thing they make for, say Rust, will be yet another thing to buy
Recently I've started using Vim bindings on my VSCode setup and although initially I was much slower than usual, now I feel confident enough to not touch the mouse most of the time. What I did was go through vimtutor every day before starting work as a warm-up and then slowly I started searching and reading around things I can improve.
262 comments
[ 3.1 ms ] story [ 259 ms ] threadhttps://github.com/JetBrains/ideavim
[1] https://plugins.jetbrains.com/plugin/164-ideavim
For example, I've found the weirdest bugs when using visual block, especially in column mode. It just completely mangles everything.
There's something to be said by having sane defaults that do exactly what you want. Probably my biggest issue with vim is you can easily find yourself in no man's land because your setup inevitably becomes uniquely your own. For example I used coc.nvim in vim, and although it worked great overall, I would often find autocomplete text sitting in an unnamed buffer that I would have to clean up. Despite googling like crazy and even asking for help in a couple vim communities, I could not solve this problem that seemingly only I had.
The article touches upon this as well, saying a 50 line tsx file doesn't work for the author in vim. For me a 1000 line tsx file works just fine, so the author managed to dig a unique hole for themselves there too, most likely.
I've tried evil-mode a few times over the years. Most recently I tried Doom Emacs twice. I _really_ want to experience the hype of org-mode. I want something like org-mode in my life. I am a heavy notes taker and I can see the value org-mode offers and I am willing to make the jump for it alone... But, I can't figure out how to get a proper workflow in Emacs that gets me to where I am in vim today. I just can't get it to click.
For what it's worth, I've been using vi(m) since the early/mid 2000s and my workflow is almost entirely terminal based for almost everything that I have ever done as a professional and hobbyist programmer. To the point that I feel like I cannot be as productive in ecosystems that are GUI based.
- use emacsclient and have aliases for emacsclient -c and and emacsclient -n for popping up a new frame or using the console, respectively. I even have a window manager binding to open a new Emacs client window
- Rainer König is the best at getting across org mode workflows. if you like watching nerdy videos, go watch him.
- keep vim around, I still use it, sometimes, but with no or veery minimal config.
- centaur tabs and the new tab stuff can help vim people who like tabs. I just got used to buffers.
- M-x is really Emacs' primary UI. don't try to think of a million and one key bindings up front, just bind what you find yourself using M-x a lot for. You just need a nice completing read like ivy, helm or so, but doom has that.
- use magit. While many claim that org-mode is the Emacs killer feature, I'd say magit is even more important if you code. There simply is no better git interface, nothing comes close. You think git the new porcelain is cool? Magit is a git jacuzzi.
You can purchase extensions for it which are all pretty cheap. You can also pay for a membership to get all extensions - this costs only $10 a year.
The creator of the app is very active in the forums and is constantly updating and improving the app. I love it and it has made my usage of org-mode on the go much easier.
[1]: https://beorgapp.com/ [2]: https://beorgapp.com/manual/scripting/
I switched to Doom Emacs about two years ago and while I miss the insane performance and simplicity of vim sometimes, the positives overall outweigh the negatives once you get over the initial differences (workspaces, command names, etc.).
Evil is great, but you end up having to know Vim keybindings and some Emacs keybindings since Evil doesn't cover everything.
It certainly can with additional Evil extensions and modifying your .emacs, but I still felt like there were some parts of Emacs where I needed to know Emacs key bindings.
God-mode works since it just makes it so that you can use Emacs keybindings without modifier keys. Everything works out of the box. Best part is that you can install extensions without needing to come up with Evil keybindings for them.
[1] https://github.com/emacsorphanage/god-mode
[0] https://github.com/syl20bnr/evil-escape
IdeaVIM get 90% of VIM right, and some things wrong (such as `u` for undo also undoing movements). Evil gets 95% of VIM right. But I have high hopes for NeoVIM allowing an actual first-class VIM implementation to be embedded, not copied, into an IDE or even Emacs.
For me, :wq closes the current buffer. For me, :e works as expected.
There might be a built in alternative to :set nu. How do you expect that to work?
I was wrong about `:e`, it does work.
Instead of `:set nu` I'm using Alt-X UpArrow+ to find `display-line-numbers-mode`, which does what it says. But there are other settings which I have on muscle memory macro that do not work, such as `:set wrap!` which I use often with my portrait monitor.
[edit]
FWIW, "gvim -v" will probably give you clipboard support in a terminal on ubuntu, and ubuntu might have an "alternatives" tool to make the "vim" in your path have X support. "The Ubuntu packager compiled vim with the feature I want disabled" is a poor argument against vim; it would be like someone saying "I switched away from vim because I wanted to write plugins in Python" just because the packaged version of vim they use has python integration disabled.
"+p pastes from the system clipboard.
The general point is right though. This is an issue with any terminal program that either doesn't allow selection of text, or has a system for selection of text that's separate to that of the terminal emulator.
https://github.com/lemonade-command/lemonade
I made a video tutorial around setting it up at: https://nickjanetakis.com/blog/getting-copy-paste-to-work-in...
2. Why would I run vim over ssh when I can use netrw with a local vim?
I just find all jetbrains products run like molasses, even with a 12-core machine with 32GB ram. I work fairly quick, and get frustrated when my editor holds me up.
Surprised to hear about the crashing issues with typescript, but I don't have any experience there.
AppCode is way snappier for me than Kotlin-in-IDEA. AppCode is also more likely to shit the bed and not be able to find a standard library class with ctrl-click.
PHPStorm has never given me trouble.
I use vim quite a lot, every day. I also use IntelliJ IDEA every day. And yes, there's a bit of mental switching I do, and every now and then I use vim navigation keys while in IDEA, but generally it works for me. Different tools for different jobs.
Then again, I have no trouble loading reasonably large documents in vim, so maybe I don't have mine quite as customized as the author.
BUT I relate to the feeling of not being quite sure that all of my customization are quite enough, of not using vim to its full potential. Or even 10% of its potential.
Some of this is particularly strong due to the language I use most - Java - where the IDE is nearly bulletproof in terms of finding exactly, only, and all real usages of identifiers (it won't ever get confused by two different identifiers with the same name) which isn't true for pycharm/python (though it does a good job honestly, but you can't blindly trust it like you can with intelliJ). I could see how someone would find pycharm not quite as much of a win over ctags, though IMO it still is.
[edit] That said, I still use vim quite a lot. I wouldn't use anything else for editing config files or just examining text content. Especially since you can pipe to it - seldom a day goes by when I don't "| vim -" instead of less or anything else.
There's a lot of built-in features in vim without requiring the installation of plugins. So, you might not need to customize it at all to use more of its potential, just read the manual.
Article literally goes "I tried to build ultimate IDE from vim, sometimes it's good, sometimes not, but then I discovered this not that free tool called IDEA and damn it works".
Vim has the advantage of being portable and installed everywhere. I can also create a new file quickly, easier than IJ.
IJ has great Perl support and, the main reason I use it, a sane integrated Git GUI, the only one I've been able to use without tearing my hair out.
Because I'm freegan, I also get free entertainment in the form of IJ's "basic" support for js, html, css.
For a long time I thought I would miss vim editing experience but IdeaVim is the best vim emulation plugin I've ever seen and I hardly can remember a vim feature that is missing in IdeaVim.
Though I have to accept occasional UI freezes and huge memory consumption of CLion.
For the moment I mostly code in Python and I settled with a very minimal setup:
1. Linting: python-mode. IMHO it provides very good linting out of the box
2. Completion: jedi-vim. Jedi for python is great. Even though with this minimal setup the completion is not asynchronous I still think it's great.
It took me some time and a recent pruning to actually arrive at this minimal setup. I totally feel it with the author that finding the right set of plugins in Vim can be a bit overwhelming.
That said, main downside to IntelliJ is IMO speed and input lag in editor windows, mainly in TSX files. I admit it's a complex language and the fact that Prettier runs on save probably isn't helping either, but still. It has trouble resolving imports, some are done automatically, others you have to select a quick fix options for, and sometimes both work and you end up with the import itself getting munged.
I was a happy VS Code user (after being a happy VIM user for a while) until I switched jobs from Go codebase to Ruby and then I quickly jumped back to IntelliJ. So far (for me) this is the only editor that correctly figures out most of the definitions and locations of methods/classes/etc.
Intellij IDEA is my go-to tool when working with the dynamic beast Ruby.
Well, actually Intellij IDEA is my overall go-to tool, also now when I work with Go again mostly.
I actually still do that even though work bought me an IJ license because my personal _suite_ license covers more tools
Still quite a lot more than I make in an hour, but definitely not $500. Are you looking at the organization pricing?
On the other hand, betting on open-source tooling may be a good way to increase the chances that your "best" tools will still be available in the future.
https://henrikwarne.com/2012/06/17/programmer-productivity-e...
I've got to say that I am still solidly in the IntelliJ IDEA camp.
I fear someday having to do job interviews and having to get up on a whiteboard or use some half-assed shared-coding IDE, because my fingers and eyes, they really want JetBrains products there... I don't type out for-loops, I use generators, etc. etc. it's all so much faster...
Last time when I praised CDT for embedded Linux developing, I was downvoted by these vim/clion lovers...
It feels to me that Vim is great at the low-level process of editing text. Everything else is fine - as good as any power editor, but not inherently great. This is the complement of Emacs, which to me is exactly the other way around.
My "problem" is that since I've been using the same editor for 30 years, I don't tend to think too much about the manipulation of text. So even the tiniest of behavior changes is unsettling to me.
Though I could probably adapt.
I should try it all again (maybe not emacs, but something), and really set up everything well for auto-complete and such (mainly C and Rust). My current vim setup (using pathogen) is sort of a mess.
When I have only a minor edit to make in the middle of typing something (like transposing two characters) it saves me the back-and-forth with the normal mode and it's really sweet.
It probably makes me an heretical freak, but I'm definitely hooked. I guess I am condemned to live the rest of my life in emacs now.
But I write R/python/markdown, so it works out fine for me.
https://medium.com/@elecming/the-ultimate-emacs-hacking-tuto...
Not sure how to feel about the goal of vscode plugin compatibility. I'd hope for a vim based ide to kind of "be its own thing".
- Moving away from config and plugins in VimL, which is extremely idiosyncratic and awkward to use, towards lua and other languages via rpc
- Long term health of the project - neovim feels like a truly community driven project, whereas Vim seems bottlenecked by Bram and his specific desires. Neovim has also gone to great lengths to make the source easy to maintain long term.
- inccommand (https://neovim.io/doc/user/options.html#'inccommand')
- saner defaults
I pretty much can't read anything on the internet about jetbrains without thinking about it being questionable.
https://news.ycombinator.com/newsguidelines.html
Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like.
Sure, there are a bunch of choices for you to use... but now you have another problem -- there are a bunch of choices.
On the flip side, if you want easy configuration, then yes, vim/emacs/similar are not necessarily the right choices for you, but I don't think that means they are generally bad options.
I don't think this advice makes sense at all. I can't maintain cc-mode and I don't understand how it works, yet I rely on it.
Users should not be expected to understand how the TypeScript autocompletion works in order to get it working. I can open VS Code on a TypeScript project and get autocompletion working just based on the tsconfig.json, much of the time.
libraries live or die based on their interface.
Hence why, despite my interest in Fish, I'm still just making do with Bash, I just can't justify the time to make a proper switch.
It would be a whole lot easier if someone put together a set of basic configs for various languages that had language servers, completion, etc. and everyone referred new people to those. It's much easier to tweak and replace stuff than to assemble an entire config wholesale.
This is relevant because COC is basically a system for talking to language servers.
https://github.com/neoclide/coc.nvim
These are not questions I've ever had to ask myself in the ~8 years I've been using IntelliJ IDEs for coding full-time.
Maybe it's easy to fix vim in this case, but it's really annoying to constantly have to Google your problem, find a fix, test out new configs, etc.
I left Linux after 20 years for the same reason. I'm happy to pay a small amount to have highly-paid software teams figure these things out for me.
The refactoring tools in JetBrains products are amazing for me. Renaming a variable and having all uses within scopes renamed too is great. Renaming classes by patterns is also great. Being able to move definitions to new files and have it update all my imports etc is great.
Not sure I see any downsides to optional tools
With high-powered auto-completion and one-button refactoring, your brain stops processing the full name. No one's incentive to pause for a minute and come up with thoughtful variable names. For most developers it's too mentally tempting to just puke out some CamelCase word salad, because the IDE hides all the effort of having to read/write/remember unfortunate names.
It's great to pause and come up with meaningful names and I agree more developers should do it, but refactoring is a normal part of coding and I'd rather have an easy way of renaming things as the code evolves.
For class names it might be true that long compound names are driven by auto suggestions from the IDE. But I'm wondering if they're really as bad as their reputation. Somehow it's similar as for variables. You can still come up with more meaningful names if you want but I admit that auto suggestions do more harm there.
I’m biased, though. I HATE gigantic supposedly “self documenting” (but utterly impossible to actually say aloud) identifiers.
My ideal identifiers are 2, maybe 3, syllables, with dashes or underscores, with actual documentation of WHY anything visible beyond The scope of a single function is used.
And I'm unsure about your point about meaningful names - IDEA typically won't suggest a name when renaming an existing language artifact - type, class, object, method, function etc.
It will when extracting an expression into a variable, based on the context it was derived from, and that's actually a pretty good heuristic - e.g., if the expression being extracted is
It'll suggest things like Most of which are what a developer would usually use in that situation.A bit of forethought when first naming things works wonders, too.
You need an editor that can understand "this usage of 'containers' refers only to class 'Zoo', so I should find all variables of type 'Zoo' which reference the 'containers' field and change those."
hence
> It's not precise, so it might take some manual work and tweaking with the patterns
and like I said,
> for how often I've had to rename identifiers, it works good enough to handle the bulk work.
so
> You need an editor that can understand
No I don't, because renaming across many files is rare enough that I don't need it.
Most of the time, I do refactoring before it's gotten out of hand and so regular vim features like I mentioned in another comment are typically enough.
In other words, I think such understanding by the editor is too much complexity (and language-constrained, at that) for little reward.
I would suspect if a language advertises it has superior reasoning capabilities about code that should also enable a superior IDE experience as well. Where are those IDEs?
I've been slightly switching the opposite way, using vim more and more for smaller stuff and opening the IDE only for larger projects or work stretches. I definitely love the value of vim as a nifty tool, my workflow is noticeably faster.
As an aside, that cheeky :wq is not missed by me at all, :x all the way!
IMO yes. My machine has like 8 total and Chrome monopolizes quite a bit.
So I can see it being an issue, I just think an IDE isn't optimized for that kind of usage, I guess? I acknowledge I'm speaking from privilege here, though, and that probably non-professional users would like to use this software as well.
For what it's worth, I just took a glance at required PyCharm specs.¹ They recommend 8GB and minimum 2GB ram, which seems a bit dumbed down. I can't imagine anyone being able to properly run it without at least 4 gigs of ram even if they have nothing else running.
[1] https://www.jetbrains.com/pycharm/download/#section=windows
The autocomplete feature is a great example of this. I do not use an autocomplete plugin at all, but rather use Vim’s native ins-completion. Combined with a language server and a lightweight LSP client (I use vim-lsc) this works beautifully.
I am excited for some of the upcoming changes in neovim however. I think the introduction of treesitter for syntax highlighting and a native LSP client will both be huge
I am often torn with the same conundrum - I've been using neovim for Ocaml, and I really just like vim as an editor, but having inline linting is really really nice. But it's also really, really complex to configure, and it detracts from why I love vim so much - if I wanted an IDE, I'd be doing my Scala work over in Intellij.
I'm still contemplating whether I can get what I want with a second window a file watcher running build commands.
Agreed the treesitter is also really exciting.