Vim as you IDE(haridas.in)
haridas.in
Vim as you IDE
http://haridas.in/vim-as-your-ide.html
19 comments
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.
You can live your life without phones, internet, buses, cars or any kind of modern technology.
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?
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 give yourself up to the Google ecosystem and live happily inside GMail, GCal, GDocs etc. You can do the same thing with Apple or Microsoft, but you can't easily mix and match between them.
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.
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.
I got your point. I explained the same thing on my summary portion of my blog. I left eclipse for Vim was after seeing its advantage of basic mode based editing. All others are just additions, you can add them when ever required. Check this out also about my detailed explanation of how did that happen to me - http://haridas.in/how-i-came-in-to-vim.html
If you're coming from Eclipse, did you check out IntelliJ's VIM plugin?
I'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.
I'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.
Cool. Right now I'm not in the java world, but it will be helpful to my friends.
Hah. Very nice :) But yeah, it's hard to talk about vim without coming across as some kind of religious fanatic joining a new cult.
Your link maybe does the best job I've ever seen. This is day 1:
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 day>tailoring a vanilla installation
>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.
>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.
My god, you make it look as though using vim is a goal for a programmer. While the actual goal is to use something like vim to do a job.
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.
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.
Oh please, stop these ridiculous appeals to novelty and hyperboles of things I
haven't said.
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.
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.
Well said.
I respectfully disagree. Choosing to use a graphical IDE or a terminal based editor is a matter of personal preference; it's foolish to proclaim one or the other as universally superior. There are pros and cons to each, and they are fundamentally different in many ways.
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.
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.
This is the issue, if you a need a vim master and a couple of pair programming session to learn what vim is, you are doing it the wrong way.
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 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.
[deleted]
I guess I'd fall into the "Unix as an IDE" camp, so I'm glad that by default Vim is "just" an editor. I think it's great fun to see how people have tricked out their Vim installations, but I confess I view those custom Vim setups kind of like I do tricked out hot rods, or Burning Man art installations. I hope people never stop producing arbitrarily complex Vim installations, because software can be art.
I agree. I also prefer the approach of making an IDE "vim-like" by adding vim keybindings and such, rather than going the other way round.
I love vim and I've used it for many years, but for programming I've found the "code understanding" features of an IDE to be as valuable as the dexterity that vim allows in terms of input and navigation. I do not simply mean syntax checking--a baseline in my opinion, but more of things like inheritance hierarchy navigation, refactoring of code (e.g. renaming all instances of a particular local variable, a particular function, etc etc, without the risk of a simple text substitution), mark occurrences (showing all of the reads and/or writes of a particular the variable under the cursor in all views), and so on. It is even better if your IDE can run parts of the compiler on the fly (an instructor once told me that eclipse does this with java. However, I'm not sure if it's feasible for something like C++ due to the complexity of the language). And then you have all of the other features of the IDE at your fingertips too (e.g. an integrated debugger or profiler).
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.
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.
Everytime someone writes a post about vim we see these editor wars emerge again and there seems no real solution, as it is mostly "use what works best for you".
There are amazing software engineers using vim, and others using Eclipse with Java on Windows like notch or Visual Studio like John Carmack.
Use whats you feel comfortable with.
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.
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.
Funny. I was at more or less that point about two years ago. My desire for more of that lead down a slippery slope that ended in Emacs. And for some reason I am now coming full circle and realize that I don't actually require a lot of these plugins any more.
I'm still trying to figure out why I feel that way.
I'm still trying to figure out why I feel that way.
If your IDE doesn't do isomorphic refactorings reliably it is really just an editor.
I really would like ctags to work well with JavaScript, but I'm using require.js and Exuberant ctags really doesn't like that.
I think it's a Vim rite of passage to write these posts. Just reading this one now makes me want to write my own, even though I know everyone has seen them a million times and has little interest in my Vim special flower.
Would anyone be interested in a writeup of my setup? Arch Linux + xmonad + tmux + urxvt + zsh + vim. No desktop environment, just a setup optimized for reliable web development. I've been building this setup from scratch at work and at home for the past year, so I've got most of the minor annoyances figured out.
First off, I'm sure that with the (recent?) surge in "check out my super efficient setup" posts, a write up of your config would be fairly well received.
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.
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.
This is the efficiency post that I kept coming back to when starting to use the command line more:
http://shebang.brandonmintern.com/tips-for-remote-unix-work-...
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/
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/
If you like DoublePane you might like size-up better. I use that and cinch but I am considering a switch to Moom. It has even more interesting features and combines the size-up features with cinch.
I've actually been looking for something like this, and Moom seems to do the trick. It's got some nice customization, so I can at least set my own shortcuts for different areas of the screen. It works really well since I don't like straight 50/50 screen splits (I prefer a sort of pseudo-golden ratio layout -- Moom can't do it precisely, but it's close enough).
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.
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'll check those out now -- thanks! :)
Interesting. What's painful about xmonad (compared to awesome)?
Haskell is a pretty heavy dependency when you're not using it otherwise, and whatever it other benefits, does not make for a good configuration file IMO.
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 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.
Interesting. while i agree having a language in the configuration is not optimal, it works a brilliantly the other way around. (i.e: a good way to get more people interested in a language.). Personally, i came across tiling WM on HN, along with haskell. and tried out. had trouble configuring or rather customizing configurations, tried awesome, but ended up on xmonad anyway, after doing 5-6 chapters of LYAH. I guess given i am a python guy, lua didn't excite me as much and ended up with xmonad + haskell. And oh, all of these took a year or so. I just recently went fulltime with xmonad.
Thanks. Your points seem valid for 'normal' people. I'm so engrossed with Haskell, that I see much stranger fish than $ and ., like <=< or &&& or <$> .
Thanks. Your points seems valid for normal people. I'm so engrossed with Haskell, that I see much stranger fish than $ and ., like <=< or &&& or <$> .
It's anecdotal, mostly, but I've always seemed to have more issues getting it up-and-running. Of course, there's also confirmation bias ("See? This is harder!") and also just the fact that I got used to awesome-wm as my first tiling WM. Sort of like vim/emacs or Ruby/Python.
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! :)
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! :)
I've been using xmonad for a few years, now. But since I'm doing Haskell for longer, still, I never though the language in xmonad as a hindrance. Quite the opposite.
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.)
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'd love to see that. I'm a fan of tiling windows and a custom Arch setup is my escape plan if OS X goes off the rails.
Actually I feel the same as you, except I'd say it's already off.
My main annoyances are the monkeying around with both the traditional process lifecycle for GUI apps, and the saving/loading of documents. I gather there has been some refinement of these (or at least more options) in 10.8, which I'll try a couple of point-releases in.
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...
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...
There's that, and also monkeying about with the trackpad (reverse scroll is okay, three-finger drag is very awkward for me), as well as hiding the Library folder, forcing use of the App Store to get Xcode, Xcode constantly crashing... I feel like I'm not part of the target market anymore.
Sounds similar to my setup: Arch Linux, monsterwm, dwb, urxvt, zsh, tmux, vim. All managed with salt[1] and keeping dotfiles in git[2].
[1]: http://github.com/uggedal/states
[2]: http://github.com/uggedal/dotfiles
[1]: http://github.com/uggedal/states
[2]: http://github.com/uggedal/dotfiles
Arch + xmonad + Screen + urxvt + Bash + Vim here, though I've found my use of Screen has dropped significantly since switching from KDE to xmonad, because the tiling is done right in the WM. I've got certificate-based login and Bash aliases set up for all my frequently accessed servers, so it's easy to open new terminals. The only real need for Screen is for stuff that needs to be persistent, but I try to avoid using persistency whenever possible, because it would just lead to me opening 100+ terminals in a Screen session, much like I do in Firefox (also not a good thing, but I haven't found a solution yet).
Arch + goomwwm + urxvt + bash + vim for me. I stopped using screen/tmux on my local machine (still use tmux on servers though) in favour of 1) keeping all my text editing in a single vim session using buffers/tabs/splits - this way I can use the standard vim commands (yank, etc) to copy and paste between files, and 2) multiple urxvt instances as goomwwm makes managing them just as simple as if I were using screen/tmux.
I also started to use uzbl as my browser. Maybe one day I can throw my mouse away :)
I also started to use uzbl as my browser. Maybe one day I can throw my mouse away :)
I'd love to use uzbl, but unfortunately there's no LastPass support (apart from some bookmarklets that can provide basic functionality).
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.
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.
Arch + DWM + URXVT + VIM here and love it. Tiling WM are so convenient. I am a little too apprehensive using Xmonad, dont have enough time to mess with haskell.
I'm using the same setup except xmonad instead of dwm. Aside from installing GHC as a dependency, I've have no need to mess with Haskell to use xmonad. And unless you're doing something crazy/brilliant with dwm, I'd doubt you'd need to hit the Haskell books either.
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.
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.
I'd be mildly interested; Debian + ratpoison + screen + urxvt + vim, here, so there's bound to be similarities but differences might also be enlightening.
Yes, very much. I'm deving with Eclipse on OS X, but have been wanting to move away from Apple/OS X since Lion appeared and a linux xmonad setup seems intriguing so have been reading up on similar things and every extra helps.
Funnily enough that is exactly what I did after the release of Snow Leopard. I came to really enjoy using Arch Linux with wmii, vim and dwb. But a kernel panic later I'm back to OSX, for the time being.
I use precisely the same setup, and love it. Full control over every tool in the whole chain.
I'd add one more that I find essential: Pentadactyl. Without it, the context switch when using a browser really disrupts the flow.
I'd add one more that I find essential: Pentadactyl. Without it, the context switch when using a browser really disrupts the flow.
I use Chromium + Vimium, which makes my entire workflow possible from the keyboard when doing backend development. I somehow managed to go a full productive day at work without touching my mouse (except to move it out of the way at the start of the day) while working on a drag-and-drop feature. Since you're using the same setup, do you have a dotfiles repo so I can take a look? Mine is kind of messed up at the moment, but here's an old revision with everything: https://github.com/chris-ritsen/dotfiles/tree/113442a72ddacb...
You motivated me to clean mine up. Here's the result:
https://github.com/tammeri/.files
https://github.com/tammeri/.files
vimium supports almost no vim keys (due to chrome snarfing them) which makes it totally useless for me
I was using Vimperator for a while, but it didn't give good experience, My chrome has also its vim plugin but it has slightly different key map, because of that I stopped using vim plugin on both browsers.
I surely want to try out the new vim plugin Pentadactyl for firefox.
I surely want to try out the new vim plugin Pentadactyl for firefox.
I'm doing primarily web dev at the moment after a loooong err, "sabbatical", just started using vim, and waiting for my drive to come so I can finally have a stable Arch boot. So yes, I'd be very interested!
Yes please! I'd like to take the dive into Arch Linux at some point, this kind of post would be super helpful.
Exactly my setup :) Although, since xmonad I don't use tmux that much anymore!
That's interesting setup. Waiting to see how it looks like.
[deleted](1)
HAH, vim looks more and more like emacs :)
As I recall, that was always the idea behind Vim. To bring the power and flexibility the author appreciated in EMACS to the style and interface of Vi.
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.
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.
Well, you've got to use your memory above the first 640K for something.
I'm sure the article is interesting, but the writing is awful.
Thanks for the feed back. Actually I'm not good at explaining things,Sorry that's not an excuse. I'm always trying to improve my language and presentation skill.
I hope you're not misinterpreting my criticism. I didn't mean to humiliate you or make fun of you, I was just trying to let you know that you should improve your writing skills. I am not a great writer, but I do try to do my best and I am sure you do the best you can too. If I was too harsh in my original comment – which it now seems that I was – I apologize.
No problem man. I understood that. :)
Many times, improvements come from just iterating over the text and rewriting parts of it. Native speakers will need less iterations, and very few people can write really well the first time round.
It's a great article. Assuming English isn't your first language, I think @insertnickname is being unfair.
I feel happy about that. I want to know how I performing :).
You're right. I have apologized to OP.
I've been content with the Janus[1] extensions for about a year now but I just added MiniBufExplorer and I'm really enjoying that.
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.
[1] https://github.com/carlhuda/janus
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.
[1] https://github.com/carlhuda/janus
I hope this would be helpful to you - https://github.com/sjl
Or I can use a text editor like TM2 or ST2 and turn on vim bindings and get 80% of the way there (that's a generous 20% for all of the vim hotkeys that don't work in the emulated modes).
What I've found with "vim modes" is that I get the wrong 80%. It's really about how you approach development; in my world, it's very editing-centric. For others, it's tool-centric. If I can get 100% of the editing environment I want with 80% of the tools I want, I'm happier than I would be with your suggestion which would be reversed.
80%? Every attempt I make to use a Vim emulation mode doesn't get 20 seconds without failing to replicate Vim behavior on even fairly basic things.
Then check out Evil for Emacs and ViEmu for Visual Studio.
ViEmu even supports something like nnoremap in its .viemurc.
Case in point: My first introduction to Vim was through ViEmu.
ViEmu even supports something like nnoremap in its .viemurc.
Case in point: My first introduction to Vim was through ViEmu.
Alternatively VsVim for Visual Studio. I prefer it, although I couldn't give any reasons why.
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.
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.
What features do they fail on typically? Have you tried Xvim? It's far from perfect(still alpha) but it's got a lot going for it. It turns out Vim has a lot of features and it takes a while to get to a polished state.
Or you can use a few plugins to get 80% of the "missing" features of something like TM2/ST2. Especially if terminal/cross-platform support is an issue.
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.
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.
If you're using a language that (practically) requires an IDE, or, you really want what the modern idea of IDE is. You probably want to look elsewhere.
That, or grok that Unix is the IDE. Vim is just the editor component.
That, or grok that Unix is the IDE. Vim is just the editor component.
There's plenty of middle ground to stand on. By choosing vim alone, you already deviated from Unix purism (rabid Unix purists aren't that happy with bog-standard vi, either).
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…
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…
You are absolutely correct. I started to use Vim as main editor (Around 6 Month) only after realizing the easiness of its command based editing, not looking after its plugins. I tried to explain that in the blog summary portion. Then why we need all those plugins ?. It just add extra features, who don't like it ?
this post might be interesting to some looking into zsh + vim + tmux
http://www.mahdiyusuf.com/post/24784023641/beautiful-tools
http://www.mahdiyusuf.com/post/24784023641/beautiful-tools
I tried zsh for a while after seeing its colorful features. But IMHO it lacks command rendering and auto complete speed compared to bash.
Over the years I seem to have gone full circle with Vim. These days I lean towards few or even no plugins - snipmate is the last plugin i'm struggling to eliminate.
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.
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.
I have been so spoiled. I have never been much of a Microsoft fan (except for Excel, best software ever) but have done most of my development in C, C++, C# using Microsoft IDE's which as everyone knows are pretty much the dogs bollocks. I do Java development using Eclipse.
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?
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?
Honestly, for an IDE replacement rather than just an editor, I'd suggest Emacs rather than Vim.
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.
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.
But if you look at Emacs-as-IDE route taken by EDE/CEDET suite, it's a kludgy beast... (I don't know how large the EDE/CEDET user community is, but most people I know forsake it in favor of the simpler facilities in Emacs).
I've found vim is the finest code editor I've ever used, but it's a crap IDE in terms of organizing a project, compiling, and debugging all from one software. Disclaimer A: I haven't spent a ton of time trying to make it an IDE, and B: I have the misfortune ;) of being an iPhone dev, and only Xcode plays nice with the devices and simulator.
If anyone can prove me wrong, please, please, please do so, because vim is just awesome for editing code.
If anyone can prove me wrong, please, please, please do so, because vim is just awesome for editing code.
Not entirely true. Appcode, an alternative IDE, also works fine with development on devices and the simulator. I haven't heard of an open source plugin to do this yet, though. So no way to do that for vim. (There's a vim plugin for app code though, it's not perfect but ok).
Ah; I tried Appcode and hated it too much to get to debugging, but it is nice that someone's figured out how to interoperate.
I didn't get how to get syntastic to check PEP8 compliance. I have it along with pyflakes, and never seen such an error (I don't believe I'm that PEP8 compliant myself)
EDIT: oh, nevermind, just needed pip's flake8 package
EDIT: oh, nevermind, just needed pip's flake8 package
I don't read tutorials written by people with bad English. Life's too short, and too many better alternatives already exist.
"too many better alternatives already exist"
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.
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.
> "too many better alternatives already exist"
> This is utterly false.
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.
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.
I agree, but also find it hilarious that this title is on the front page.
You'd almost think the mods on HN were more interested in screwing up useful titles than fixing ones that are actually broken.
I like to tell myself it's a principled protest rather than heartless moderation.
http://en.wikipedia.org/wiki/Work-to-rule
http://en.wikipedia.org/wiki/Work-to-rule
Ha.. ha.. Actually I missed the 'r' while posting it on HN and I noticed it after an hour. No way to change the title. I tried to proof read my article to make it correct as much as possible.
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.