Vim as not IDE
I wanted to write something useful for a long time, but I didn’t know what I could share, and then I came across another article about the reasoning, what is still better - vim, emacs or IDE? At first I wanted to write a comparison of IDE and vim, but I did not use the IDE too much and am afraid of being biased. Therefore, I will simply describe the reasons why I use vim. Just to show that editors occupy their niche. I will also try to talk about the problems I encountered using vim and how I solved them.
I am a fan of * nix-like systems and have heard that in every such system, there is always vi by default (although it happens that this is not always the case). And once I had to write a program on C for a well-known linux distribution, I didn’t have a question about using IDE - I just opened vi and quite often opening the cheat sheet I started writing code. Immediately, I’ll note that at that time I used vim as an ordinary editor and did not use all the power of the command mode.
It was a great student time, now I am an engineer. It so happened that the technological stack did not have to choose and I began to write in php. Everyone knows that one of the best IDE for php is PHPStorm, although there are still many others, including free ones. However, all my colleagues, as one, recommended PHPStorm to me and I did not ignore the advice of more experienced developers. This IDE is really good, it has everything a web developer needs, but there was a problem: the IDE worked very slowly.
The speed of work was no good. I had a laptop with intel core 2 duo (2 cores of 2.4 Ghz, if I remember correctly) 3 GB RAM and HDD. There is no money for a new iron, the junior’s salary is not high and you don’t want to take loans, and are unlikely to give it.
')
The project consisted of ~ 1.5 GB of source code, a database on Oracle and used some specific libraries. He also had very large resource files (XML) that he had to manage with his hands.
PHPStorm lagged awfully, it started up a long time, searched for a long time, even hung when I just edited the text, it simply could not open more XML.
The first thing to say about vim is that without writing a config and additional plug-ins you cannot program in it normally. But if everything is set up, then you can live. And second, vim is not an IDE and you shouldn’t make an IDE out of it. Even if you screw a hundred plug-ins, it will not be the same as PHPStorm or <your IDE could be here>.
But development is not only code editing, it is analysis, refactoring, debugging, moving through files, and so on.
I solved this problem with the plugin ( NERDTree ), in it you can see the tree of files, manipulate them, etc., but there is also a built-in file manager in vim.
Static analysis of the code and display of its results in the editor turned out to be also a simple task, also solved by the plugin, and for any YaB I know.
I use vimgrep or ack to search through files, it may not be as effective as in the IDE, but even in a huge project they work quite fast. Finding the files themselves and opening them for editing can also be done with a bunch of find or grep + vim commands or directly into vim via a plugin (for example, ctrlp ).
I never managed to make friends with the debugger. Or rather, there is a plug-in for communicating with xdebug, but it is not very convenient to use it, but the value of this tool was kept to a minimum, callstack can be seen, and the rest is a matter of technology. Now I don’t write to php anymore and use console tools (analogs of gdb) as debuggers and there are plenty of them.
Inspection of the code thing is not as necessary as it may seem, I have a plugin ( tagbar ), but I rarely use it.
Normal movement to the definition works only with C and its derivatives, for php, ruby, python, etc. I was unable to configure, but I quickly got used to using ack and vimgrep.
There are so many plug-ins for autocomplex that you won't try everything, but over time I decided for myself that this is not such a useful thing. It is worth noting that for some it is very important, because very long names of methods, classes (hello, java) are used, but if you want a more or less adequate autocompit you can configure.
Enabling support for a new language is usually solved by connecting the appropriate plug-in, for example, for golang it is enough to connect one plug-in that can do everything (from backlighting to static analysis and auto-formatting).
Vim works well with large files out of the box, but for giant files there is also a plugin ( LargeFile ), when using it you can even open gigabyte files and nothing will hang.
Auto-formatting code is out of the box and it automatically hooks up settings from plug-ins for different languages.
I use git and I do it in bash, but for some operations I put a couple of plugins ( vim-fugitive , nerdtree-git-plugin ).
The most important feature of vim is the modes. There are many of them, but the most important is normal, or command mode. After some time, albeit long (2-3 months), I almost completely edit the code in command mode. Of course, I switch to insert mode when I need to write something, but otherwise I use commands. This allows you not to take your hands off the keyboard and after a while you stop thinking about how you edit the code and you can fully concentrate on what changes you need to make. Perhaps the most successful example is the piano, when you learn to play on it, you start thinking only about music, not about what keys to press. And I can definitely say that the hot keys will not give such a result (I tried for a very long time - it did not work).
In those conditions in which I worked, with a weak iron and a huge project, IDE was used to flour, but a bunch of standard * nix-tools and vim made it possible to solve all the problems that stood before me. Now I also work in vim, but already due to the fact that I do not want to relearn myself and change the familiar environment that has shown itself well. Over time, I work more and more efficiently, because vim and * nix-systems are things that can be studied for a very long time and constantly find new methods for solving various problems.
And if you don’t want to use IDE or don’t have enough money for a cool paid version, I recommend that you try editors such as vim and emacs. If you understand their ideology and it will be close to you, then you will not experience any problems with the work on the code.
But I must say that this is all important for me as for a backend developer, perhaps for developing GUI applications or frontend, the editor will not work.
How I met Vim
I am a fan of * nix-like systems and have heard that in every such system, there is always vi by default (although it happens that this is not always the case). And once I had to write a program on C for a well-known linux distribution, I didn’t have a question about using IDE - I just opened vi and quite often opening the cheat sheet I started writing code. Immediately, I’ll note that at that time I used vim as an ordinary editor and did not use all the power of the command mode.
The time of small programs has passed, now everything is serious
It was a great student time, now I am an engineer. It so happened that the technological stack did not have to choose and I began to write in php. Everyone knows that one of the best IDE for php is PHPStorm, although there are still many others, including free ones. However, all my colleagues, as one, recommended PHPStorm to me and I did not ignore the advice of more experienced developers. This IDE is really good, it has everything a web developer needs, but there was a problem: the IDE worked very slowly.
The speed of work was no good. I had a laptop with intel core 2 duo (2 cores of 2.4 Ghz, if I remember correctly) 3 GB RAM and HDD. There is no money for a new iron, the junior’s salary is not high and you don’t want to take loans, and are unlikely to give it.
')
The project consisted of ~ 1.5 GB of source code, a database on Oracle and used some specific libraries. He also had very large resource files (XML) that he had to manage with his hands.
PHPStorm lagged awfully, it started up a long time, searched for a long time, even hung when I just edited the text, it simply could not open more XML.
Vim again
The first thing to say about vim is that without writing a config and additional plug-ins you cannot program in it normally. But if everything is set up, then you can live. And second, vim is not an IDE and you shouldn’t make an IDE out of it. Even if you screw a hundred plug-ins, it will not be the same as PHPStorm or <your IDE could be here>.
Editor to edit, but ...
But development is not only code editing, it is analysis, refactoring, debugging, moving through files, and so on.
So problems
I wanted to see the project files as a tree structure.
I solved this problem with the plugin ( NERDTree ), in it you can see the tree of files, manipulate them, etc., but there is also a built-in file manager in vim.
Understand that I made a syntax error during editing.
Static analysis of the code and display of its results in the editor turned out to be also a simple task, also solved by the plugin, and for any YaB I know.
Have a quick file search and have a quick file search
I use vimgrep or ack to search through files, it may not be as effective as in the IDE, but even in a huge project they work quite fast. Finding the files themselves and opening them for editing can also be done with a bunch of find or grep + vim commands or directly into vim via a plugin (for example, ctrlp ).
Run debugger from editor
I never managed to make friends with the debugger. Or rather, there is a plug-in for communicating with xdebug, but it is not very convenient to use it, but the value of this tool was kept to a minimum, callstack can be seen, and the rest is a matter of technology. Now I don’t write to php anymore and use console tools (analogs of gdb) as debuggers and there are plenty of them.
Have a code inspection tool
Inspection of the code thing is not as necessary as it may seem, I have a plugin ( tagbar ), but I rarely use it.
Move to the definition of a method or class
Normal movement to the definition works only with C and its derivatives, for php, ruby, python, etc. I was unable to configure, but I quickly got used to using ack and vimgrep.
Have autocomplete attached to the project
There are so many plug-ins for autocomplex that you won't try everything, but over time I decided for myself that this is not such a useful thing. It is worth noting that for some it is very important, because very long names of methods, classes (hello, java) are used, but if you want a more or less adequate autocompit you can configure.
Multi-language support
Enabling support for a new language is usually solved by connecting the appropriate plug-in, for example, for golang it is enough to connect one plug-in that can do everything (from backlighting to static analysis and auto-formatting).
Work with very large files
Vim works well with large files out of the box, but for giant files there is also a plugin ( LargeFile ), when using it you can even open gigabyte files and nothing will hang.
Auto Format Code
Auto-formatting code is out of the box and it automatically hooks up settings from plug-ins for different languages.
Integration of version control systems
I use git and I do it in bash, but for some operations I put a couple of plugins ( vim-fugitive , nerdtree-git-plugin ).
Editing as it is
The most important feature of vim is the modes. There are many of them, but the most important is normal, or command mode. After some time, albeit long (2-3 months), I almost completely edit the code in command mode. Of course, I switch to insert mode when I need to write something, but otherwise I use commands. This allows you not to take your hands off the keyboard and after a while you stop thinking about how you edit the code and you can fully concentrate on what changes you need to make. Perhaps the most successful example is the piano, when you learn to play on it, you start thinking only about music, not about what keys to press. And I can definitely say that the hot keys will not give such a result (I tried for a very long time - it did not work).
Summarizing
In those conditions in which I worked, with a weak iron and a huge project, IDE was used to flour, but a bunch of standard * nix-tools and vim made it possible to solve all the problems that stood before me. Now I also work in vim, but already due to the fact that I do not want to relearn myself and change the familiar environment that has shown itself well. Over time, I work more and more efficiently, because vim and * nix-systems are things that can be studied for a very long time and constantly find new methods for solving various problems.
And if you don’t want to use IDE or don’t have enough money for a cool paid version, I recommend that you try editors such as vim and emacs. If you understand their ideology and it will be close to you, then you will not experience any problems with the work on the code.
But I must say that this is all important for me as for a backend developer, perhaps for developing GUI applications or frontend, the editor will not work.
Source: https://habr.com/ru/post/265441/
All Articles