Square open-sources its Vim repo, Maximum Awesome(corner.squareup.com) |
Square open-sources its Vim repo, Maximum Awesome(corner.squareup.com) |
spf13-vim is built to be a base and completely customizable. This is built to be your vim config.
Lastly spf13-vim has dozens of contributors supporting a variety of plugins and languages. This seems focused on squares stack, ruby & coffeescript.
Disclaimer... I'm spf13, so a bit partial, but if you look at spf13-vim from 2 or 3 years ago it looked a lot like this... and we've learned a lot from making some mistakes present here.
I remember having tried it once and abandoning because it lacked this feature (or didn't work out of the box).
If you are using it with something like fuse or expandrive you are not using it over SSH but on local files.
If you are using it in a remote Vim via SSH, you are not using it over SSH either.
If you did something like :e scp://foo//bar/ and see a directory listing you are not using NERDTree.
Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.
It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.
Otherwise, nice work and good job open-sourcing it!
To a newcomer like me, Vim's built-in help was less than worthless, since you pretty much need to know the Vim term for what you're looking up to find it. Googling around wasn't much more effective (there's a lot of garbage in the Wikia for Vim that comes up at the top of many searches).
In the end, I needed to read these two "gentle" introductions to Vim to even understand what it was all about:
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...
…and then I needed a mostly-well-documented distro like Janus (https://github.com/carlhuda/janus) to ensure that my productivity wouldn't take a huge hit those first few weeks.
Some folks can probably go all-in cold turkey, but I needed the training wheels.
Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.
Those braindead distributions are just smoke mirrors for lazy and pressed people: they provide training wheels but they actively prevent you from actually learning core Vim. They make people $distribution_name users instead of Vim users.
That was my experience as well. I was pretty comfortable using vim in emergencies but the few times I tried to make it my full-time IDE failed very quickly. Once I stole Gary Bernhardt's dotfiles[1] I was able to stick with it because I didn't have to start from scratch with keymaps, plugins, etc.
I started vim by using cream[1], which behaves like a normal editor with menus to configure everything. Once you get used to the different concepts, you can start editing the `.creamrc` file. After a few years, I was comfortable enough to drop cream completely and use hand written vimrc file for the configuration that I liked.
What exactly was it you were doing faster and better in your previous editor (which was?)?
> the environment [was] too extreme & foreign
What about it was weird?
This said, I think these sort of dumps are great for experienced vim users who can pick through them and find individual fragments that they want to adopt.
Basically it follows the KISS, and in some sense UNIX, principles.
I have never used the vim distros but I have gotten to a point where I just rm -rf'd my whole .vim dir and started over with only the plugins I required at the time. Then added more as I needed them.
Of course, I have always managed well without the file browsers many use.
That said, I started using vim with Janus and while it convinced me that vim could be a great modern editor, it left me too confused when I tried to make my own customizations. I ended up ditching it and hand-picking my own plugins. I suspect a completely new vim user would likely experience the same process with Maximum Awesome. Still, that doesn't mean these curated sets of plugins are a bad idea--if anything they can serve as a proof of concept for people who aren't yet convinced on the value of the editor.
Not to mention it's not maximum awesome: CtrlP > Command-T and Vundle > Pathogen.
I disagree on that front. Managing git repos is easier for me to do the way I always do it than with a slightly auto-magic system specific to those sort of git repos. Pathogen does a little, but does it flawlessly. Vundle does more, but the more it does is far less elegant.
http://www.codeography.com/2013/06/17/replacing-all-the-thin... https://github.com/Shougo/unite.vim
I also worked with the author of CommandT at that job, which was nice.
Emphasis on "for them".
I'm not saying you shouldn't share your setup. I wouldn't have learned vim (or screen back in the day, or pine, or many others) if I didn't crib from the dotfiles of those before me.
But at some point, your setup becomes so customized to you that you're the only one it works for. And that's why vim and emacs, ancient editors, still exist -- they're stable and can be modernized and tailored to the user over time.
This writeup (not mine) I completely agree with: http://mislav.uniqpath.com/2011/12/vim-revisited/
Starting from blank and building my own dotfiles is what did the trick for me. Using a big ass template actually made it more difficult.
Because they have different purposes, they must be compared according to your needs.
I don't need a "plugin manager" but I like my plugins to be organized cleanly so I use Pathogen.
If you need something to help you "manage" your plugins, Vundle is a sensible choice but you should compare with VAM or neobundle.
In short, comparing Pathogen and Vundle makes no sense: compare what's comparable.
https://github.com/tpope/vim-pathogen#installation
It's literally copy and paste. I understand preferences and taste, but you make it sound like you need a degree in particle physics to make the thing work...
Please make sure you have the correct access rights and the repository exists.
Checking connectivity... done Submodule path 'vim/bundle/jshint': checked out 'da21f0eb658d9af6696ee34a00c13d1717d85095' Cloning into 'vim/bundle/kwbd'... Permission denied (publickey). fatal: Could not read from remote repository.
Overall, this seems like a great way to get started with vim because it doesn't have too many plugins but it still has the minimum features expected from someone who used Sublime or Textmate.
edit: looking at their .vimrc, there's a lot of stuff that I'll use right away. Definitely useful, just not as a straight download/install for me.
If you use ruby/rails try yadr https://github.com/skwp/dotfiles. If you don't use ruby, it (imo) still has one of the best key maps/configs for beginners just delete the ruby plugins.
Make it yours: :help every plugin and every setting if you don't know what it does. Change any key mappings you don't like. It will take about 40 hours to familiarize yourself with everything, that is if you go plugin hunting yourself. I'm not a believer that starting from scratch is the way to go.
Remove vim-snipmate, neocomplicache, vim-snippets, vim-colors-solarized. Remove nerdtree nerdtree, vim-nerdtree-tabs, use :e/CtrlP instead.
Add YouCompleteMe, vim-detailed, vim-notes, vim-slime, vim-numbertoggle, vim-abolish, vim-startify, vim-textobj-rubyblock, switch.vim, ultisnips, vim-airline, unite (check out unite plugins), vim-expand-region, vim-jsbeatify, extradite, vim-diffchanges, vim-speeddating, goldenview or golden-ratio.
This config probably won't run well on machines that are older than 2012, in total there are about 90 plugins. Remove any plugins you don't need. Look up how to profile your plugins, if one of them is causing things to be slow remove it. Don't install anything without reading the help file immediately afterwards.
Learning enough vim to match your current productivity is not as difficult as everyone makes it out to be. I was instantly more productive with this setup switching from RubyMine and I still have barely scratched the surface of those help files. Disclaimer: I had picked up the most basic motion / visual selection keys previously working over SSH. And I was familiar with window/buffer management from using tmux daily.
To everyone I highly recommend YouCompleteMe, vim-detailed, vim-notes, and https://github.com/rking/vim-detailed.
I know a few basic vim commands (switch modes, edit, write, quit) but have never used it to work on a complete project in a directory.
In the mean time, keep using ST on your projects.
https://github.com/christoomey/vim-tmux-navigator
"Seamless navigation between tmux panes and vim splits"
So great. Off to check another random side-project off the list...
[1] https://github.com/tpope/vim-pathogen [2] https://github.com/gmarik/vundle
Also does anyone see where they are setting the /// to comment? Commentary uses gcc and I don't see it in their vimrc.
Yes, lots of people use <leader>something mappings because they offer a lot more flexibility than <C-something> and friends. What you use as mapleader is up to you, "," is simply the value suggested in the doc.
P.S. I mapped `Q` to recording Macros, since the default use of `Q` is completely useless to me.
sudo xcode-select -switch /Applications/Xcode5-DP6.app
To get the command=T to compile
and I get:
$ git clone git@github.com:square/maximum-awesome.git && cd maximum-awesome && rake
Cloning into 'maximum-awesome'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
update: i like the empty line space indicators little boxes look cool
I switched to CtrlP last week because I switched OSes at work and didn't want to recompile vim and Cmd+t. In the past CtrlP was significantly slower, but I found a few new features that actually makes it faster than Cmd+t for me; it automatically navigates up looking for a .git or .svn to search from instead of cwd, and you can set up caching (persistent between sessions) and max num of files to scan--I believe you can set a timeout, too. I also setup a filter so my build folder and docs won't show up.
Since finding Cmd+t, it's been the fastest way to navigate to files in a project (especially when they're not in the same directory).
Oh God, here we go...
gitgutter, ctrlp, and pretty much anything from tpope are all great in this regard: they do one localized thing and it Just Works. (Downside is when that "one thing" is a shortcut or function, and with no other cues I forget I even have the plugin installed.) On the other hand I've had pretty terrible experiences with SuperTab, which required a lot of fiddling and still breaks my Tab key sometimes, and ctags is such a pain that I've never gotten around to making it actually work. But those are useful enough that they end up in most plugin bundles, so you get a Cartesian product of the interference and brokenness of all of them.
Also nice is the TMUX integration.
Basically, terminal multiplexing solves a different problem than window management solves. Terminal multiplexing gets you detach/reattach (letting you switch computers trivially), per terminal splits (which I frequently use in addition to WM tiling, similar to how I use Vim windows in addition to both of those), and better scrolling/highlighting.
I've picked up a few new tricks from their setup as well -- e.g. see the "Fix Cursor in TMUX" comment in vimrc.
It's not like tmux didn't get any love these days.
I think it is a lot harder for people used to IDE's, but if you treat it as "get to the minimum productivity level as fast as possible, then slowly add more", you will probably enjoy it.
No one appointed you the director of how one learns Vim.
This is one of the most obnoxious parts of Vim threads: that guy that responds to people talking about how they learned Vim (past tense, as in already happened) and tells them that they learned it "wrong".
My first intro to Vim could be called "haphazard" at best because I was pressed at the time, and so that thoroughly soured the relationship. It was only after I took a few steps back and went at it with a let's try this again attitude very slowly did I finally get through it without exhausting myself. I wish I took the slow route the first time.
Best way to learn Vim is to learn it for the sake of learning it. Not because "it's in the way".
For me, vim didn't take until I used it start to finish on a smaller, week-long project and immersed myself in it. Everyone learns differently.
In practice I've found bundler to be just another layer that can have the wrong version: http://xkcd.com/927. But I have no interest in bringing up old painful episodes, I'm done with the ruby eco-system. So I'll just restrict my response to the previous paragraph.
* The ability to run this engine in the background.
* A unified API that would make possible for plugin authors to interact seamlessly with that engine but also between each other.
* Certainly a thousand of minor details.
You can add as many fancy plugins as you want, you'll never get an IDE.
You'll get something that looks more or less like an IDE and works more or less like an IDE, but not an IDE because an IDE is not a text editor with a file explorer on the left, a class explorer on the right and a list of compile errors underneath. It is much more than that and Vim doesn't have and can't have that "much more".
Unless you count external compilers/debuggers/profiler/linters as that "much more" but that's still not an IDE. A DE, maybe, but certainly not "I"ntegrated. Well, not even an "E"nvironment, actually, given Vim's design principles.
If you are running tmux locally it would allow you to do things like kill X, log back in, open a new xterm, then pick up where you left off. The session isn't paused or suspended, it continues running the entire time even though the gui terminal emulator died.
If you are running tmux remotely, then it lets you start working at home on your laptop (over ssh), close your laptop, drive across town, turn your laptop back on, ssh back in, and pick up where you left off.
The way I use this at work is I have many long-running tmux sessions running on my desktop (one for each 'project', and one for a few interactive db sessions and the like). I then work over ssh with a fullscreened Putty instance. When I want to switch projects I can just hit C-b s then select the session I want to switch to.
At home I use a laptop with linux (and the Awesome WM (similar to xmonad, though less hardcore I suppose)) but most of my 'work sessions' are on various other machines. I ssh into them and connect to the correct session with tmux. Since Awesome lets me arrange windows with tags I do that a lot for work sessions (like tagging a few terminals and a browser window that has docs opened in it) but I consider those to be more ephemeral. I close them out when I start running low on resources (memory, cpu, battery, etc) but the tmux sessions live on (local or remotely).
(I use to use straight up xterm as well, but switched to urxvt because my new laptop has a high DPI screen that makes urxvt's nicer font rendering support sort of necessary.)
How is urxvt's font rendering support better than xterm's?
Having
XTerm*faceName: Inconsolata
XTerm*faceSize: 14
(P.S. Awesome is not at all less "hardcore", just works differently and is kind of a required taste.)
That's a pretty narrow definition of an IDE, especially since the history of IDE's goes back far before a time in which any IDE could be said to have a core engine that understands the code you write. In fact that "requirement" is almost entirely driven by the rise of Java and the ridiculous amount of code it forces you to write. Prior to Java IDE's I can't think of a single IDE that could be said to have such an engine, including Visual Studio who's features in that regard were driven by competing features in the Java world.
The 2nd requirement is obviated by the lack of the first; the 3rd and arguably the 4th are already present in vim. An IDE, at its core, is exactly what you claim it is not: a text editor that provides navigation features (possibly but not requiring a class navigator—you seem quite focused on object oriented features) and an ability to run the code under discussion. Emacs very definitely is an IDE under the limited definition you provide, including an engine for understanding the code you write.
I'm also not sure about why you think external compilers/debuggers/profilers/linters are disqualified from being the core engine you're fixated on—you realize that every IDE out there does exactly that, right?