Vim as you IDE
haridas.in
haridas.in
The reasons I say this is every time somebody brings up the apparent ancientness of vim/emacs people point to something like this. I agree that all this is doable, but you must realize tailoring a vanilla installation with plugins to do all this is really difficult for most programmers. Especially if you want newbies to start with using vim.
If people wanted to use an IDE, they would use an IDE- There are plenty available these days. All it takes is going to go to the eclipse website, and downloading one. Why in the world would any body spend hours(days?) hunting all these basic plugins which are must have for today's software development needs?
Somethings like auto complete in ST2 looks to just give what the user wants. In vim you would be doomed press ctrl-n as and when you need it, but it happens automatically with ST2.All these modern GUI based editors are basically these many tiny optimization on old concepts .There is also that file browser that gets opened by default on the left hand side. The minimap on the right hand side. The search functionality using ctrl-p. These are few tiny yet useful automations that should ship with vim/emacs by default. I see no reason why they shouldn't. Apart from trying to sell themselves as endlessly customizable editors, they must also do many of tiny day to day needs by default.
Things like package managers, a proper good looking GUI et al are must have things in any software tool these days. Arcane 80's style GUI, default tooling support for software development needs going two decades back is not going to fly.
Yes, vim is old, but it's not a web browser - it's for manipulating text (or in our case, code), the process of which has changed little in the last 30 years.
Before writing vim off, pair program with someone who is masterful at it and you'll see some if its many pros first hand. Yes, this may take (quite literally) years of use and customization to achieve, but no, it's certainly not something you can write off as obsolete or inferior.
Why is it wrong to enable auto suggest by default? Or the file browser or minimap by default? Why not enable directory level grep/search by default? Why do you need to learn two decade old arcane 3 fold command sets for simple search-replace. Why aren't line numbers turned on by default? Why not provide tabbing by default?
None of what I have mentioned is something uncommon to developers. Every developer needs to this almost everyday with his code.
If you see modern day GUI based editors, they are basically designed to solve these daily little recurring annoyances and made available to you out of the box without you have to do to too much of tinkering. Like everything needs of developers change with time.
Software usability is a very important aspect of software engineering.
My primary concern is in assuming the usage of difficult tools as geeky and cool. By merely learning how to use a two decade difficult to use tool doesn't make a person a great programmer.
Why in the world would any body spend hours(days?) hunting all these basic
plugins which are must have for today's software development needs?
You are used to the file browser on the left, the minimap on the right, the search function bound just so. So you want that. But not all vim users are used to that.
The simplicity of vim is what drew me. There aren't a hundred and one "project files" (whatever those are) added to any bit of code I want to work on. There aren't a hundred and one buttons everywhere. There is the code on the screen. Nothing else.
Adding lots of extra file-trees and variable-lists and computer-guessing-what-you-want-to-do in the default vim install seems like it would scare away more users from vim than it would draw. For the modern GUI kid (like me and I assume you), getting used to modes and the vim keybindings was hard enough. Let the user add windows and features at her own pace, as she gets comfortable.
One other thing before you write off the "arcane 80's style" editors:
The second fact that drew me to vim is that it was esteemed by men who I respected.
Look at the powerful minds that have built such beautiful things with vim and emacs. There are two explanations for their devotion to their editors:
1) They are used to vim/emacs. They like them because they are used to them.
2) They are technologists. They have an innate fascination with the novel, the bold, the capacity for an innovative idea to change everything. Yet even with this prejudice, they love truth enough not to sacrifice the old superior tool for the new, fashionable one.
After the first few frustrated sessions with vim, where I cursed at it for not behaving like a text editor "should" behave, I believed very strongly that explanation 1 must be true.
But the power (sorry, that's the right word) I feel when I fire up vim grows everyday. It grew today after reading this excellent blog post and discovering some new, wonderful plugins. And everyday I grow more convinced that explanation 2 drives the loyalty to vim.
Your link maybe does the best job I've ever seen. This is day 1:
*monday*
“eclipse sure is neat.”
“but that weird guy with the neckbeard at work looks really fast with vim,
I should try it!”
“alright! I got gvim. this doesn’t look bad. there are even menus!!!”
“wait what? where’d my text go? wait. undo. no.”
“:help”
“:q!!!!!”
.
.
revels in the opiatic relief of autocompleting boilerplate
in eclipse for the rest of the dayI'm a decades-old Vim user, but I still fire up IntelliJ for Java Android development. Java is less painful in an IDE that was designed for it, and with the IntelliJ plugin it's like having one's cake and eating it too.
And yes you will need them only if you have used them. Because people around a century back didn't need them.
You can still live in a jungle. But the question is, should you?
You can pledge yourself to a single programming language. You can live and breathe Java all day and become a master of it and its tools and world views.
But the question is, should you? Should you give up the richness and flexibility of all that is out there and hedge your bets in ONE technology stack and ONE IDE?
Vim and Emacs and ST2 are language agnostic. The Unix command line is language agnostic. In fact, it is text editor agnostic, too. You can mix and match the tools and languages you like.
IDEs with all their richness are fairly confined to a very narrow set of languages and methodologies and ways of thinking about problems.
Both choices offer different benefits and different downsides. Make your choice wisely.
>newbies to start with using vim.
Sorry, but what? The very last thing a newbie programmer should be doing is configuring plugins. A newbie programmer doesn't need plugins. They only serve to confuse. Which is also why the very worst thing you can do to a newbie programmer is to give them an IDE.
vim is perfect for newbies. It just works, and the defaults are mostly sane[1]. Yes, there's a slight learning curve, but you can do basic text editing (enough for writing any Hello World program and then some) after taking 20 minutes to do vimtutor, and from then on it just gets more powerful.
You can add plugins when you actually need them. A newbie doesn't need plugins. They just need a good text editor - and vim (and Emacs) is the best you can get. No fancy editor or IDE of the week will ever change that. Not Eclipse, not Visual Studio, not ST2, nor whatever else.
Another thing: I refuse to take anyone serious who even brings up the "argument" of "arcance 80's style GUIs" and/or "modern GUIs". Why? Because in the overwhelming majority of cases, that means "vim doesn't have drop shadows, it sucks"[2] (or some variation of that).
Nobody even knows what a "modern" GUI is supposed to be. It's just a fuzzy way to say "I don't actually have any tangible arguments against $thing so I'm just going to accuse it of not fullfilling unwritten, non-existing standards that no one has ever agreed on.". Or in other words, bullshitting.
[1]: Really, the only things I did when I started with vim was to ":set number" and ":syntax on", then put that in the .vimrc. That's it. Everything else was added on demand.
[2]: Yes, I actually had someone trying to argue this to me. I closed the comment page and burst into laughter.
The original argument is modern day editors aim to automate most recurring demands of a programmer out of the box.
The point in most pro-vim/emacs arguments it to make you take the most difficult route to achieving text manipulation tasks. Hoping that will make you good at text manipulation over time. While the point is you are trying to gain a expertise which you don't need.
Going by that argument you don't need any kind of an modern GUI ever. Why ATM's? Why graphically friendly email clients? And you could go like this for nearly everything.
You need modern editors because you always need to take steps forward in the usability game.
You keep spouting "modern" without any sense whatsoever. The fact that vi(m) and Emacs are both veteran pieces of software does not somehow reduce their usability. They are still the most usable and powerful editors on this planet. Yes, they have a (steeper) learning curve. No, that isn't a bad thing. Please stop conflating usability with accessibility[1].
>The point in most pro-vim/emacs arguments it to make you take the most difficult route to achieving text manipulation tasks.
You don't make any sense at all. If anything, vi is the easiest route to achieving text manipulation tasks. The better you know it, the easier, the faster and the more efficient it becomes.
>Going by that argument you don't need any kind of an modern GUI ever.
By what argument? Your own confused interpretation of what I haven't said?
I said that there isn't even such a thing as a "modern GUI". It's an idiotic term that has no defined or agreed-upon meaning, and is thrown around as a pseudo-argument in discussions like this. It has no merit and can be dismissed as such.
[1]: I've made this point countless times in the past, in all sorts of different discussions about software. People keep on blabbering about how $software (like git, vi or just GNU/Linux in general) is unusable when they really just mean it's a bit more challenging to learn than, say, nano or gedit, completely ignoring the long term benefits.
I'd add one more that I find essential: Pentadactyl. Without it, the context switch when using a browser really disrupts the flow.
I surely want to try out the new vim plugin Pentadactyl for firefox.
http://arstechnica.com/apple/2012/07/os-x-10-8/18/#automatic...
http://arstechnica.com/apple/2012/07/os-x-10-8/5/#document-m...
I used to prefer Awesome in part for the tweak-it-while-it's-running appeal of Lua configuration, although I rarely used it. Now xmonad has the same runtime configurability via GHC, with recompilation taking a second at most.
The real reason I'm responding is to throw in my $0.02 that for those that want an easy and efficient tiling window manager setup, but don't want to go through the relative pain of xmonad, `awesome` is a great substitute. I've used it for years now, and although my office hardware changed from an old-ish ArchLinux box to a Macbook Pro, I'm still an avid fan of tiling WM's. Even on OS X, the first app I install is always 'DoublePane' to mimic the functionality. [1]
As efficient as vim shortcuts can make you while banging out code, I am a firm believer that most window managers are absolutely and completely inefficient. Most people whom I convince to give a tiling, scriptable WM a try never look back.
It's vim efficiency for everything you do!
[1] I'm not affiliated with DoublePane in any way, and there are alternatives out there. That said, for $1.99 (last I checked), it does an incredible job of increasing my efficiency on my Mac.
Pretty good use of $10, I think, unless I suddenly need that $10 for an emergency, like beer or coffee or a raw turkey. So, thanks, even if I'm stuck without a supply of raw turkey for a week.
I'm seeing a lot of people respond about using similar setups with different tools. It doesn't really matter whether you use awesome/xmonad/ratpoison or something else, but I can tell that the people who built the tools I use think about computers the same way I do (https://wiki.archlinux.org/index.php/The_Arch_Way). I'm striving for this: http://blog.sanctum.geek.nz/series/unix-as-ide/
The biggest issue for me is that although xmonad and awesome are both completely scriptable/configurable -- one of the benefits of having conf files that are "alive" -- xmonad is configured through Haskell while awesome is done through Lua.
To me -- a security guy who can sling code from scripting languages all over the place, but doesn't do any functional programming -- Lua is much easier to understand and use. Not everyone feels this way, and a lot of the configuration is just setting variables anyway.
I know many people who swear by xmonad, some of whom even used it at my suggestion, so please don't take this as a "beware" message. Try both out, and see which you like! :)
As a security guy, even though you're more familiar with Lua et al, wouldn't you have a warmer fuzzy feeling with a strongly statically typed language? (I use Python every once in a while. But having to wait for the running time for detecting basic faults always gives makes me nervous.)
I don't really know what to think about the trend among some software of having a full programming language in use in the configuration file. It seems like a good idea at first, having all that power at your disposal, but it really complicates things at times. Especially when the language in question is far from the normal languages in use. If you ever find yourself wondering why the $ or. operator was needed in someone's configuration you'll see why that's a bad idea. (yes, I know if you know haskell the reason will be clear. The point is that you shouldn't need to know details of a programming language like that to configure a WM)
Awesome isn't entirely guilt-free with its Lua configuration file, but at least Lua is similar enough to languages like Ruby and Python that you can mostly get what's going on in a config file without having learned Lua specifically.
I also started to use uzbl as my browser. Maybe one day I can throw my mouse away :)
So I've stuck with Firefox but have installed Pentadactyl, which adds Vim emulation support. It gets me close enough to avoiding mouse use as I think I'll ever get.
This is more than likely a factor of my environment though. I'm frequently using Vim "away from home" so to speak.
Best approach for this i've found so far is to set a $VIMINIT on remote login (i.e. an admittedly clunky combination of SendEnv set for Host * in ~/.ssh/config). Still on the lookout for a better way though.
Always wanted to know what to use as a general purpose IDE that is ideally cross platform and was looking for opinions on whether these VIM layouts might be suitable?
If anyone can prove me wrong, please, please, please do so, because vim is just awesome for editing code.
Reasons:
* Emacs plays well with other programs, you can start other shells, language interpreters etc, from within Emacs and interact with them easily. There are some Vim plugins that try to enable this but I've always found them less satisfying.
* Emacs is usable in all the same scenarios as Vim (i.e. cross-platform, over ssh, dual GUI/Terminal ability, screen/tmux/dvtm compatible etc)
Random Thoughts:
Vim is an amazing editor but I've always found that these attempts to add features to make it into an IDE cause it to start to feel clunky.
Emacs on the other hand, plugins generally work well (except when they don't).
Vim (or at least vi) is installed on basically every Unix install (and available for install everywhere). Emacs is installable everywhere also but setup generally takes a bit longer.
If you are going to use Emacs and you are intrigued by Vim style keybindings, I've found Emacs Evil-mode to be one of the best Vim emulation packages that I've tried (most Vim emulation packages will eventually cause frustration - Evil mostly doesn't).
I find that I use Vim more when I'm switching between a lot of different computers, and Emacs when I'm mostly developing on one stable computer setup.
So my workflow in a particular environment is usually, first install Vim so I can get work done, and as I use the environment more I'll end up installing Emacs and gradually switching over to it.
That, or grok that Unix is the IDE. Vim is just the editor component.
Saving round-trips to she shell ain't necessarily evil. Separate unix tools are great, but e.g. presenting info in the editor is quite helpful. Ctags does your parsing, but you can display it with tagbar. Language-specific tools do linting, but you can display it in the editor with syntastic…
A few years ago I searched high and low for something satisfactory that combines the text editing/navigation of vim with the extremely useful features of an IDE. The closest thing I could find for C++ was Netbeans combined with the jVi plugin. The VIM functionality provided by such a setup is not too barebones, and the IDE fills in the gaps where other VIM plugins may have been used. There may be something better now, but I've grown accustomed to this setup and it takes a substantial amount of time and effort to reroll.
There is also Eclipse CDT and the "eclim" plugin for it (which actually uses an existing vim process. Since this means that all of the other vim functionality and vim plugins work in tandem with the IDE, this is the ideal setup), but I recall that there was much lacking with both Eclipse CDT and "eclim" itself (I do not recall exactly what, but, again, this was a few years ago). Things may be different now and I encourage anyone looking for something similar to take a peek at both Netbeans with the jVi plugin and Eclipse CDT with the eclim plugin.
There's value to be found in taking the best of multiple worlds into one product.
I for example, cut my teeth on Bill Joy VI, and the keystrokes are burned permanently and naturally into my brain. I love the extra stuff that Vim gives me, because it is a natural extension of that toolset that I started with.
I typically keep three panes open, one of which is NERDTree. Right now my biggest gripe is the strange highlighting of the Play! framework's template files. The files are name.scala.html which results in weird highlighting of the inline Scala. I have yet to find a good solution (admittedly I haven't looked in a while) to this but if someone knows of one I'd love to hear it.
Personally i like the simplicity of vim for editing taks, i could see me writing javascript or any other scripting language with it. But for complex software i definately would miss the abilities of modern IDEs, be it only for refactoring.
I'm still trying to figure out why I feel that way.
EDIT: oh, nevermind, just needed pip's flake8 package
Whatever floats your boat, any half-way decent expandable editor should be able to emulate other editors features with some effort.
Corollary: Whatever you do, there still will be some rabid CygnusEd fan complaining.
ViEmu even supports something like nnoremap in its .viemurc.
Case in point: My first introduction to Vim was through ViEmu.
It still fails the "Does it break flow by not implementing some feature or other?" test fairly frequently though. First thing that comes to mind is that while it has text objects, it seems to be lacking "tag" though (vit, not vi<). Which is a shame, as it's quite useful for web dev.
This is utterly false. In academia you will find numerous peer-reviewed journals which have high percentages of non-native English speaking authors. You'd probably find many articles in such journals to contain "bad English". But they're often doing totally original research and so, no, better alternatives don't exist.
We live in an era where English is the de-facto language of the internet and some of the most brilliant people aren't native speakers of English and so might be considered to have "bad English". Not reading their work seems like a perfect way to miss out on learning things you might not otherwise learn.
There are tutorials on VIM in English that are well written. Many are good. Thus, my claim is not "utterly false" it is true. If I did not think it was true and had not seen evidence that it was true I would not have said so.
> Not reading their work seems like a perfect way to miss out on learning things you might not otherwise learn.
There is an overflowing abundance of material from which to learn in the world. In English alone, even. And there is only a small finite amount of time and energy that I have available for focusing on it. Thus I try to filter out the crappier stuff. Thus I filter out things in bad English when better alternatives exist. This does not seem like an unwise strategy.