Awesome work Dan. If you keep putting out awesome Vim stuff like this, I'm really going to have to ditch Textmate at some point and join the club.
For those of you who haven't seen before, Dan is putting out some awesome software like this about every 2 months it seems. And it is always awesome and useful.
This feels akin to counting all time in gmail as "work" regardless of what one is reading/writing. The most dangerous distractions are those which disguise their presence.
The mental burden of task switching is about changing mindsets, not applications. The damage here is equal whether you're looking for an album in vim or a gui.
So I suppose that you don't want to try the same programmer's Vmail[1] - a Vi-interface for Gmail? (Oh, or even better Twim[2] - a Vi-interface for Twitter!)
More seriously, I thought of it as (1) a cool hack and (2) akin to Zawinski's law[3] about the way that software expands to consume more tasks. More serious Vim hackers might object that it amounts to the Emacs-ification of Vim. (Given the number of plugins to add calendars, todo lists and Org-mode to Vim, I think that battle may be lost.)
I've been using mutt with gmail. It drops into vim when it's time to compose a message. I've never heard of vmail. It sounds interesting, but I would personally recommend mutt over vmail. mutt is quite vimish.
You don't have to store your password in plain text just because it gives you the opportunity to do so - I use mutt without a stored password for IMAP. It means that I have to enter my password between one and three times per day, but that's a minor inconvenience to me.
While I tend to agree in general, I've actually found pianobar much less distracting than the Pandora web interface.
F5 (my hotkey for Terminal.app), n, Alt+Tab can happen without me really thinking about it, whereas the web interface requires firing up the browser, locating the "Next" button and clicking it.
So I guess I can see this being an improvement if all you're looking to do is skip to the next song. If, as you say, you browse through your albums, etc, then I imagine this would be just as distracting.
I agree with you that the claim that this is some sort of "productivity enhancement" is a bit weak, but as an actual feature, it is pretty impressive. The productivity side of it is immaterial, IMO.
I would have expected you to pick different key bindings though. for example ,y instead of ,c for copy or ,/ instead of ,s for search. Is that because you already have those binding for something else or do you just find them more intuitive?
Interesting; I didn't realize it was possible to control iTunes from alternate frontends via some sort of API. Instead of a new console-mode frontend, though, I wonder if it'd be possible to adopt player frontends from other client/server music players, like the ncurses-based 'ncmpc' frontend of mpd.
iTunes can be controlled via AppleScript. This plugin appears to talk to iTunes via a CLI the author wrote in Objective-C which uses Scripting Bridge to talk to iTunes. Scripting Bridge is a cocoa interface to scriptable applications.
Many OS X applications expose part or all of their functionality via AppleScript. To get some idea of what an application offers you can fire up AppleScript Editor, then open the dictionary for a given application. (Rarely, an application will expose more than is shown in its dictionary.)
Now, AppleScript is a truly detestable language, so avoid using it directly at all costs. :-) http://appscript.sourceforge.net/ is much more friendly.
My first thought was the other way around: How much would I need to do to make ViTunes control my mpd music? (There seem to be a couple of older Python Vim plugins to do this[1][2].)
I haven't looked into ViTunes, but most Apple applications are very able to be scripted via AppleScript. If I had to guess, I would think that this is how this is being accomplished.
Wow, gem install && run the install utility and 'it just works.' What a cool project, and impressive that it just does what it claims to do, well and in such a jazzy manner.
I believe those studies were done with non-experts. Editors like vi and emacs are expert-systems: the upfront cost to learning how to use them is high, but once you pay that cost, you can be extremely efficient in them. I've used vi (well, vim, but just about anyone who uses "vi" is really using vim) as my primary editor for... eight years now. I feel far more comfortable in it than in editors that expect me to do mouse-and-keyboard inputs. I am, however, not a master. If you've ever seen vi or emacs masters write or edit code, it's clear they are faster than they could be if they were in a mouse-and-keyboard interface.
The key thing I noticed in the relative study is also that they said people experienced literal amnesia about the additional time required to choose a shortcut.
I'd be interested not only in a better study of the effect of expertise as well as looking at the effect of this "amnesia" on productivity. Even if it takes me longer to do a task in Emacs, that amnesia suggests that the interface is less distracting, which might be far more valuable than speed.
Absolutely agree. The comment was mostly tongue-in-cheek anyways. Also, not having to switch applications is a great time saver of course. By the way, there are also great apps like Bowtie or Coversutra that add global shortcuts to control iTunes
That study was done in 1989, without experts, before standardized keyboard shortcuts, and in a lab setting rather than actual usage. I really doubt its relevance today, and I'd like to see an updated look at it. I don't think it should be cited as often as it is.
I'm surprised A) anyone takes that too seriously in the past 10+ years and B) there haven't been more current studies.
Regardless of what the studies say, I often get comments from 'average' users about how fast I type and work. It's all keyboard shortcuts. I remember first seeing a guy using the tab-complete stuff in a shell - I was shocked, because I just thought he was typing fast at first, then he showed me the tab key use. My life hasn't been the same since.
By comparison, when I watch other people use a computer ('average' people), it's like I can watch their thought process as they grab for the mouse, move it around, the sloowly start moving it to a menu, then they click around and move the mouse over each selection, pausing, then moving on. It's painful to watch, and often seems to happen in slow motion.
So... keep the studies going on. Until they study power keyboard users against power mouse users, my money's on the keyboard.
That depends on how many keystrokes it takes compared to the equivalent mouse actions. `c3E` is faster than moving you hand to the mouse, highlighting three words of text that you want to replace, and moving your hand back to the keyboard.
Assuming ViTunes uses a similar set of actions to play music, I could easily see it being a faster way to find and play the songs you want to listen to.
How does this compare to something like Alfred, where you hit something like option-spacebar, type "itunes uprising" and hit enter to start playing it?
Yeah, that's what I'm afraid of as I slice and dice in vim. But short of recording an editing session for an hour, making note of the things I actually edit, and then trying it with both keyboard/mouse and vim a few times each, I'm not sure how to empirically determine which is faster for me.
Also, a lot of people compare it to "moving your hand allll the wayyy over to the mouse and back", but I do a lot of coding on my laptop, actually, with my trackpad just inches away from the home row.
I could potentially even learn to use the trackpad with my thumb without even leaving the homerow. I wonder if anyone uses it that way?
I truly appreciate the goals of this project but I honestly don't understand why the author didn't come up with his own unique name for this; there already is a vitunes (which I have used on OpenBSD).
I am a fanatical Vim user who listens to iTunes frequently while working. But I don't see the point of this.
It takes very little time for me to switch spaces and click to change playlists, and I only need to do that a few times per day. Why clutter my Vim config with another plugin? Why claim valuable key bindings, both in my config and in my brain, for something I can already do well enough?
I'm not trying to be overly critical; if you like this, use it. But to me it feels like "let's order pizza from Vim!" or "let's compose symphonies in Vim!"
Your use case and mine, for example, are different. I generally am not a fan of playlists, personally. Occasionally, but not often, I'll want to listen to the same set of tracks again but more often I want a new mix every time. Worse than that, I don't know an hour from now what I'll want to listen to so I find that I generally can only fill out a playlist a couple songs at a time.
Since I need to manipulate my now playing often, having the ability to do so through vim would be basically godlike.
Now, if only it worked for a media player I actually used :/
I love this hackery and I'll definitely mess around with it, but in the end it's probably easier just to use the media keys on my keyboard. I don't necessarily feel a huge need for vim to do everything, or I would have switched to emacs instead :)
Great job my friend, I do all my editing work on vim, both in Linux and Mac.
Now I can't wait to arrive home and try this on my Mac, unfortunately I can't have iTunes running in Slackware :(.
* http://www.emacswiki.org/emacs/itunes.el
* http://www.geocities.jp/tmjb2006/itunes/itunes-mode.html
* http://www.mahalito.net/~harley/elisp/osx-itunes.el
(I don't think any have a GUI as nice as ViTunes)