Live data from Hacker News

Square open-sources its Vim repo, Maximum Awesome

corner.squareup.com

101–110 of 145 posts

Re: Square open-sources its Vim repo, Maximum Awesome

#102

Am I missing something? What makes this "maximum-awesome"? This is your average vimrc with the regular plugins you seen in every vimrc over at GitHub.

Because it's Square and they're hip. Whenever they open the lids of their macbooks its you know... just awesome. Not to mention it's not maximum awesome: CtrlP > Command-T and Vundle > Pathogen.

I like unite + vimproc more than CtrlP:

http://www.codeography.com/2013/06/17/replacing-all-the-thin... https://github.com/Shougo/unite.vim

Re: Square open-sources its Vim repo, Maximum Awesome

#103

Earlier quoted context omitted.

Completely respect where you're coming from, but totally disagree. I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign. 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…

The problem wasn't the "extreme & foreign environment", the problem was that you thought wrongly that you could learn Vim as if it were a regular editor. 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 ac…

> Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.

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".

Re: Square open-sources its Vim repo, Maximum Awesome

#104
post #13

Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar. 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…

Completely respect where you're coming from, but totally disagree. I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign. 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…

For me it was using pentadactyl for a while beforehand that made switching easier. Obviously there are different concepts and some different default keybindings but pentadactyl is much easier to incrementally get used to imo.

Re: Square open-sources its Vim repo, Maximum Awesome

#105
post #90
post #82

Earlier quoted context omitted.

How is vim + tmux any better than gvim + xmonad + terminals? Just out of curiosity, I may want to test this setup.

(I use vim+tmux+urxvt+awesomewm) 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.

Can you elaborate on this? I also use XMonad in connections with a simple xterm (although I used screen some years ago, but then I did not know about XMonad) but I do not get the idea of detaching/reattaching. Is the idea to save the state of the session?

Re: Square open-sources its Vim repo, Maximum Awesome

#106
post #13

Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar. 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…

Completely respect where you're coming from, but totally disagree. I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign. 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…

> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.

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.

[1]: http://cream.sourceforge.net/

Re: Square open-sources its Vim repo, Maximum Awesome

#107
post #13

Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar. 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…

Another thing that people often forget when they use plugins on their development machine is that if they happen to ssh into server (or work on another user's machine), it is unlikely that it will contain the same plugins. It is better to become effective at using the bare vi/vim commands first and only use plugins as a time-saver.

This is true for using plugins in any editor/IDE. Where do you draw the line. Should I use my own `.vimrc` file and set textwidth, formatting-options, indenting, etc. according to my preference, or don't tweak anything at all because those tweaks will not be available at another user's machine/ssh server? It is relatively easy to have your configuration files on a USB/dropbox and copy them on a new machine if needed.

Re: Square open-sources its Vim repo, Maximum Awesome

#108
post #90

Earlier quoted context omitted.

(I use vim+tmux+urxvt+awesomewm) 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.

Can you elaborate on this? I also use XMonad in connections with a simple xterm (although I used screen some years ago, but then I did not know about XMonad) but I do not get the idea of detaching/reattaching. Is the idea to save the state of the session?

Sort of.

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.)

Re: Square open-sources its Vim repo, Maximum Awesome

#109
post #97
post #23

Great to see some love for tmux. Terminal vim + tmux is a lot more powerful than Gvim or MacVim. 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…

Indeed, it's very unfortunate that tmux doesn't run on windows (under cygwin).

It used to be very unfortunate, but J Raynor recently posted a working patch and I'm currently running tmux in Cygwin!

http://www.marshut.com/mrnsr/patch-for-tmux-on-cygwin.html

Re: Square open-sources its Vim repo, Maximum Awesome

#110
post #101

I find it fascinating that my set-up looks nearly the same already. :)

Nothing here is fascinating to me. Many devs confuse Vim for an IDE. Not sure why... Don't get me wrong though, first thing in every Debian install I do is to replace vim-tiny and nano with vim as the default editor. I like to think I appreciate vim for what it is, not for what it can be forced into.
Post reply on HN