1. 2
  1. 33

    Am I missing something, or is that a whole article? Looks like an excerpt or preface though :)

    But from what I see, your problem isn’t a vim itself, but rather plugins and overloading yourself with them. A common mistake for Vim newcomers is that they come in and just skip the vi grammar part (calling it “the boring theory stuff”) and trying things too hard. Then they discover plugins and – more importantly – plugin managers, which lower the bar dramatically. Within such conditions, they start to feel “safe” and install as many plugins as they can handle to mimic their previous IDE, their colleagues’ IDE or any IDE they pretend to be better from, just to show off maybe.

    And after all, you end up with a pretty much beefied up editor which you don’t really know. Okay, well, you know how to open it, type the text, save and call it a day. You know “how”, but now “why”.

    In every editor which has been thought reasonably from the ground up (not just vi - it could be emacs, joe, sam, acme, kakoune, vis, CygnusED, EDLIN…) you need to understand the rules. It’s like speaking in new dialect of your language or swimming - won’t come overnight which sounds unpleasant in age of instant grafitication, but its long-term benefits are hard to overlook.

    So, in other words (or as people say these days - tl;dr), your problem is that you don’t grok vi (or any other editor, as I said).

    Of course, if you want to just click ok and go on with things, you might just spawn up your web browser^W^Wtext editor called vscode, throw a ton of plugins on yourself and cheer. Would be that faster? Maybe. But only in short-term goal or if your project isn’t going to last more than year or two (which is a standard nowadays). Or if you just don’t want to “spend time on these neckbeardy things”.

    1. 3

      So, in other words (or as people say these days - tl;dr), your problem is that you don’t grok vi (or any other editor, as I said).

      I’m not sure how these words hold up to someone who calls himself a “VIM master from using others’ plugins to rolling out my own”.

      After seeing some colleagues working at lightning speed with PhpStorm I gave up thinking vi(m) is always faster, especially on the cases the OP mentions like renaming/refactoring classes, functions and files in a big project. The reason I still use vi for everything, is because today I mainly develop in C, which is natively supported in vi and because I can use vi for everything, not only development but also sysadmin, mail composing etc.

      1. 3

        You said what I was thinking in more words.

        1. 2

          Am I missing something, or is that a whole article? Looks like an excerpt or preface though :)

          This is ‘part 1’, so I presume they split it up to increase their exposure, which means we will probably see part 2, 3, 4,…,N of this poor article here over time.

        2. 25

          The only real problem I see here is that the author expect Vim to be an IDE.

          Let’s clear this out once again: vim is a text editor, not an IDE. The text editor should only be a small part of your programming environment. If you want a full IDE, you already have one!

          Vim is only supposed to deal with text buffers, it’s is not supposed to be aware of a project hierarchy, external tools and whatever. The first thing I do when I want do deal with the compiler, or filesystem, whatever, is pressing ^Z to get a shell, and use combinations of make, find, grep and sed to do what I’m trying to do. With a good VCS you even get unlimited undo for your whole project tree.

          You should stop using vim when you consider writing a 9 line function to rename a file… And the same applies to the other points reported by the author:

          How about duplicating a file for creating an admin panel section for the same API? Good luck with that :D

          cp file1 file1_admin

          1-Find and replace a word in a whole project? You have to install a plugin like ack.vim and figure out how to work with it easily

          find . -type f -exec sed -i "s/\<foo\>/bar/g" {} +

          2-Find and replace a word in a selection? You have to know how to work with visual selection magic :%V%s/foo/bar/g in VIM language

          As @skrzyp stated, you get to understand the tools you use if you want to be efficient with them. So grok vi.

          3-Have a good feature rich syntax support? Probably if someone created it in GitHub otherwise you have to wait or create your own and also you cannot get the same results as other editors even if you use MacVim

          Isn’t there a syntax file for every single language already? Do eclipse/atom/intellij support brainfuck syntax ?

          4-Creating a new directory/file in the current file path? You should learn how to work with VIM expand variables and run a couple of bash commands

          mkdir + vi newfile would do it just fine.

          5-Creating a new plugin for VIM? You should learn a weird language that VIM uses in a weird way :)

          Same goes for any IDE plugin

          6-Listing project directory? You should install nerdtree but it’s not even close to what you think compared to VSCode or Atom

          git ls-files, find, tree, noice, mc or even nautilus !

          This article looks more like a vim ragequit after struggling using it for 6 years.

          1. 4

            I wish I had more upvotes to give, this is spot-on.

            Unix was originally designed for two separate but very similar tasks: text processing and development. All those tools in /usr/bin are not arcane knowledge which is now obsolete in the 21st century, they’re there because they work and have stood the test of time. Do they take some learning and practice? Yes, of course. As does anything.

            I’ve been a vim user going on two decades now but over the past couple of years I have been spending more and more time in vscode with the vim plugin installed. The main things I like about it are the clickable tabs and the ever-present file tree on the left. These are incredibly useful on projects with multiple files (which is almost every project). Plain old vim and gvim don’t do these well and yes I have tried a lot of plugins. Almost everything else about the editor I try to ignore or disable.

            1. 2

              I’d argue that for smaller projects, you don’t need find, just sed with a nice shell glob. At least that’s the way I do it. But otherwise, that’s exactly what I think.

              1. 2
                6-Listing project directory? You should install nerdtree but it’s not even close to what you think compared to VSCode or Atom

                git ls-files, find, tree, noice, mc or even nautilus !

                Also netrw which is the default directory browser in vim.


                1. 2

                  I’m a fan of your work anyway, thanks for reply :)

                  Yes, I decided to move on from VIM, i3wm, Linux distrubtion ricing and it’s only my dicision and I think it’s better to no convince beginners to learn VIM, Emacs or any other advanced tools that have high learning curve but I know VIM works for a lot of people and I respect that.

                  1. 1

                    There is nothing wrong with convincing beginners to learn advanced tools. The issue is convincing them to use them. You can’t just use vi or emacs, you have to learn how they work and understand their concepts to make a good use for it, otherwise, they’ll end up in the same situation as you were: hammering nails with a nailgun.

                2. 13

                  A lot of these points sound like “you need to learn Vim in order to use Vim, how terrible is that!” This person certainly doesn’t seem a “Vim master”.

                  1. 5

                    Can anyone “master” Vim in only 6 years? I’ve been going 10 and still don’t use hjkl.

                    1. 5

                      I’m pretty comfortable with them, and use them frequently (though not exclusively), due to a misspent childhood playing an inordinate amount of rogue-like games on a laptop without a numpad, and think a good chuck of the whole hjkl thing is just wankery. There are dozens more useful things to learn about Vim: motions, text objects, macros, autocommands, buffers, etc. etc. It’s a micro-optimisation at best, and “look at how cool I am, I can use hjkl” is a large part of it.

                      It didn’t take me very long to “master” Vim, maybe 1-2 years in total. I don’t know every feature, and avoid using some features (like split windows, I don’t like them), but I know they exist and I understand the concepts.

                      Vim’s documentation is very good, there are tons of other resources, and a helpful community (mostly anyway). I found it much easier to learn than its reputation. That being said, it’s a different way of doing things that may not suit everyone’s preferences (which is perfectly fine, of course).

                      1. 2

                        Oh, I agree completely. I was being a little facetious with hjkl. I’ve treated learning Vim like learning a new language, so I always feel like there’s something more to learn – some way I could be doing what I’m doing more efficiently or ergonomically. Usually there is, unlike many other editors where there’s a ceiling to what you can learn.

                  2. 4

                    Well first off, I almost hate to complain about this because it seems to petty, but the author really needs about fifty commas to make that article more readable.

                    More fundamentally, he seems to complain a lot about things that Vim isn’t really good at and shouldn’t be done in Vim. Most of these file and directory manipulation things are better done in Bash. How much time are you really spending renaming files anyways? Meanwhile, he seems to have no words for what really makes Vim great - rapid manipulation of text without needing to use a mouse or think too much. It also sounds like a case of too many plugins - other than language support plugins, I have basically 4 - NerdTree, CtrlP, Surround, and Ack. My Vim never locks up. Maybe don’t install a bazillion sketchy plugins to do things you should be doing in Bash anyways?

                    1. 1

                      Yes, I’m not a native writer and I have a lot to learn thanks for your reminder I’m trying to get better :)

                    2. 4

                      I started to think as a professional that these concerns are much less important to me than shipping features you’re paid to ship features not spend time on your editor to make it look better or finding new ways to do things which don’t make your productive by any indicators.

                      Urgh, I really dislike this “business” at all costs mantra we see in programming these days. Is it really necessary to extract every possible last cent of value from everything we do? Maybe it’s ok to leave some money on the table and just be content.

                      1. 3

                        The IDE approach (single tool integrating all the operations) and the VIM approach (VIM just to edit a file, other tools in Unix to perform other operations) are different. It’s ok to prefer one or the other. It’s OK to change from one another. It’s fine, really.

                        Learn what you want and your tools and change them if they don’t suit your flow. Evolve and change your opinion. Enjoy.

                        1. 3

                          I used vim a lot especially when IDEs were slow and resource heavy. They are still resource heavy but a modern computer can handle them pretty well in these days.

                          An IDE provides a full view of your project with lots of navigation, introspection, and refactoring capabilities. These are priceless and more important than fast text editing capabilities.

                          Vim served me well and I appreciate it if I am in a slow network or low resource environment. However, these are rare occurrences. Finally, I love it nostalgically, reminding me my old days. But I moved on long time ago.

                          1. 4

                            Vim is a genius idea with a sloppy realisation. First time I tried it, I spent a month learning it and setting everything up to be just perfect. But then I changed job and stack, and I have had to set everything up again, and I wasn’t as patient the second time. After a few more times, I understood that I can’t be bothered to spend a few weeks testing all the plugins and remembering all the shortcuts every time I need to get acquainted with a new language or change computers and operating systems – I guess it happens to me much more often than to the greybeards.

                            On the other hand, modern editors like VSCode just work. They’re not ideal, and you may have to try different plugins as well, but I’m not afraid that editor will hung for a half a minute or indefinitely (which happens a LOT with vim plugins), and you don’t have to remember any magical Leader-something shortcuts: just type Ctrl/Cmd-P, and all the plugin’s functions are there, with useful search. I still install vim plugin on any IDE I use, and, of course, the support is lacking (for example, relative line numbers and relative movement over closed folds is something that plugin developers usually don’t get right), but these things I can live with.

                            I wish that when I retire, I will finally have time to set up Emacs with evil mode from scratch and will finally have an editor that I can configure and program in a language that I love. But it seems as a project that would take a couple of months (during which I will not be able to use it as an editor and will often break it), and for now, I have work to do.

                            1. 13

                              I’m not afraid that editor will hung for a half a minute or indefinitely (which happens a LOT with vim plugins)

                              I have literally never had that happen. This sounds like the “Wordpress plugin problem” to me:

                              1. Install Wordpress.
                              2. Install loads of crappy plugins.
                              3. Get 0wned.
                              4. Blame Wordpress.
                              1. 1

                                Well, if there are a lot of crappy plugins that turn up as first results in Google, you can definitely blame the ecosystem. And you can certainly blame the software with a plugin architecture designed in such a way that a bad plugin can bring down everything, without an easy way to isolate or at least identify the culprit.

                                1. 3

                                  Both modern Vim and Neovim support async operations now.

                                  1. 3

                                    And yet, a fresh install of spacevim on top of neovim in latest Ubuntu in WSL hangs when I try to save any Haskell file. Making a good plugin architecture is not about allowing plugins to do stuff; it’s about limiting their power to do it.

                                  2. 1

                                    blame the software with a plugin architecture designed in such a way that a bad plugin can bring down everything

                                    You can’t edit the buffer by both a plugin and the user typing in it, so completely avoiding any locks is a logical impossibility.

                                    an easy way to isolate or at least identify the culprit.

                                    Profiling (:profile start vim.profile :profile file *) usually works, or vim --startuptime.

                                    1. 3

                                      I’m not a plugin developer for any IDE, and I’m familiar with these ecosystems only as a user. And as a user, I know that I have never seen any plugin hang Visual Studio, VS Code, Sublime or other “modern” editors, but I’ve seen it many times with Vim.

                                      Now, I specifically say that I blame not the editor code itself, but the whole ecosystem. This includes not only plugin API, but also best practices that plugin developers get nudged into. From my experience with different ecosystems, I would make an educated guess that Vim plugin developers do certain things in a naive and potentially bad way (which leads to bugs and freezes that I experience) not just because they are allowed to, but because that’s how they’re taught to do it in tutorials, documentation, by looking into other existing plugins, and so on. Which, in the end, makes Vim a bad editor for me. Because just as quality of language is not only about the spec, but also about the amount and quality of libraries written for it, the quality of an editor is also about quality of plugins that I can use with it and overall level of trust or caution that I, as a user get accustomed to; that’s exactly what the word “ecosystem” stands for.

                                      1. 4

                                        Every ecosystem has loads of crap plugins/libraries. Sturgeon’s law: “90% of everything is shit”. Your entire arguments sounds like “I have experienced one plugin misbehave, therefore the entire ecosystem is bad”. That is actually a generous reading, as it could also be a misconfiguration or something else. I’ve seen people copy/paste some pretty silly things in their vimrc without understanding what it does.

                                        If VSCode works well for you: great. Go for it! But I don’t see why you need keep repeating the strange claim that it’s somehow “normal” that Vim frequently hangs. I can assure you it’s not, and “greybeards” – as you charmingly call them – do not spend all of their days waiting for Vim, or spend their entire time configuring Vim.

                                2. 6

                                  I’ve never understood the point of overloading vim with plugins. On the one hand the arguments are “it’s the same everywhere” and “it’s start-up time is minimal”, etc. but all of this seems defeated when you try to turn Vim into an IDE. Unix is supposed to be the (I)DE, and vim is the editing component, while the shell is supposed to mediate between all the other tools one would use in the process (as opposed to Emacs, where Emacs itself mediates). Or that’s at least the idea.

                                  1. 2

                                    Well, that’s the idea that makes vim a bad full-blown editor, and one of the reasons that OP, me, and other like-minded developers quit vim even though we love the modal editing aspect of it.

                                    1. 2

                                      Vim is already an IDE out of the box; it comes with completion, make integration, code navigation, a file browser, and many other IDE-like features.

                                      The problem is that a lot of plugins duplicate these features because they want to “make it seem like Jetbrains”, instead of using the Vim way of doing things. In many ways it’s similar to “Vi key bindings” that you get in many other IDEs.

                                      1. 3

                                        I wouldn’t consider any of those things to be what make an IDE. They’re not strictly vi-ish, yes, but an IDE should take things further, ideally creating a seamless interface between everything, taking charge of the more complicated parts for the user.

                                        1. 1

                                          Well, you could argue all day about what exactly an “IDE” is, but if we take the broad definition of “comprehensive facilities to computer programmers for software development” (lifted from Wikipedia) then think Vim fits the bill. It’s certainly a different approach than, say, Visual Studio, but I don’t think that makes it “not an IDE”. It’s certainly more than just an “editor”.

                                  2. 2

                                    Despite it being technically possible to do so, it is very difficult to use Vim as a file manager and IDE. It also looks like the author hasn’t quite made it up the initially-steep learning curve in the area of manipulating text.

                                    It might be possible for the author to get comfortable with Vim by doing two things: 1. Open it to edit a file, close it when done. 2. Push up to the flatter part of the editing learning curve. Once you are comfortable with the ‘with this - do that’ approach, the legendary efficiency starts to appear. Before that, you feel like you’re worse than with your previous editor.

                                    I use various IDEs (with vi keybindings), zsh (with vi keybindings thanks to readline), and the OS-offered graphical tools - and very often open Vi(m) from a shell prompt to make quick edits.