I'm sorry, HN isn't AIM or Facebook. There's no way for anyone to know who you know unless you tell us, and even then I fail to see how the comment is relevant.
At 11:25 Eastern, https://status.heroku.com/incidents/386 was posted: "We're currently experiencing a widespread application outage. We've disabled API access while engineers work on resolving the issues."
I think you're missing the point that many developers choose vim over "modern" editors because of its highly efficient text-editing capabilities. The same points could be made about emacs.
As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it.
That a foot-pedal might make vim more usable has nothing to do with vim being outdated or unusable. Is your operating system broken / outdated because one might find a food pedal driving "alt-tab" more usable or fun?
If you know vim I'd assume you already know the answer. If you know vim and don't know the answer, I guess vim just doesn't work for you. But for many others, it does. I'm not going to enumerate what's already covered in endless blog posts, SO answers, books, IRC logs, and .vimrcs.
That doesn't really answer the question, does it? The other poster made an assertion about VIM being more efficient. I would like to get a list from him (or her).
Funny enough, not one person is stepping up to the plate to justify and quantify the claims that vi/vim are/have "highly efficient text-editing capabilities".
Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are purely tribal.
In this show they demonstrate, among other things, how tribal behavior can be taken to an extreme. It is very hard for some to go against group behavior. They show one example of a guy in a room that stands up when everyone else stands up and he doesn't even know why.
To some extent I believe that some of these tools are like that. You work in a shop where the hot programmer swears by vi/vim and you adopt that without challenging any of it. Very soon everyone is playing the same tune, facts be damned. I happen to be one of those people that does not engage in crowd behavior. This can be a blessing and a curse. I never bothered to spend months on vi/vim because every time I used for days or weeks (out of not having other choices) I came out of it with the distinct idea that the whole thing was just short of lunacy. In the context of the project that needed to be completed these tools offered no real advantages. You are not going to impact the bottom line in any measurable way.
Put another way: If you took two kids that knew nothing whatsoever about computers or programming and set out to teach them. One is taught with modern mostly-GUI tools with "conventional" keyboard shortcuts while the other has to use command line and vi/vim. Both of them have to complete the same project. The vi kid would be absolutely smoked by the other kid in no time at all. No question about it.
OK, how about a second project. Maybe not smoked, but no significant gains would exist out of the vi camp. Programming is far more about things that have nothing to do with text editing. Projects are not late or buggy because of good or bad text editing tools.
I'd still like to see someone quantify the gains offered by vi/vim over the course of a project.
Furthermore, "the other has to use command line and vi/vim. " seems to be confused. Using vi style editing does not really have anything to do with the command line (though it frequently does, that is out of choice, not necessity).
If you want to test multiple versions of IE, you need to do some time intensive VM cloning to trick VirtualBox into thinking they're actually separate images. Then configure and install IE's debugger tools for each image. Then, when the VMs expire in a few months repeat that process.
Add to that the problem of VMs booting slow, running slow, and consuming tons of memory on my otherwise-fast dev machine.
> If you want to test multiple versions of IE, you need to do some time intensive VM cloning to trick VirtualBox into thinking they're actually separate images.
No, you don't. You just run different images. Downloaded from MS. I have them installed. Right now. IE7, IE8, IE9. IE9 is currently running. Even still, for the most part, IE9 makes debugging easy, as you can run in IE7 and IE8 mode. That takes care of the rest of the problems I've faced.
Yes, testing in IE sucks. It's not an enjoyable experience, but it also doesn't take much effort.
> Then configure and install IE's debugger tools for each image.
This is not an issue. You make this sound like it takes a lot of work. It's not.
> Add to that the problem of VMs booting slow, running slow, and consuming tons of memory on my otherwise-fast dev machine.
I'm running this on a MacBook Air. Yes, they aren't lightning fast, but they are usable for debugging purposes.
> Then, when the VMs expire in a few months repeat that process.
That's not true, either. I've been using my IE7 one, for example, since October.
sorry, what distinction are you drawing between "generated" and "compiled"? even "combined", for all intents and purposes, doesn't discredit the point:
if she was editing the wrong files, the answer is to do a little more research before diving in.
Just an example from my experience; if you're using lesscss and you're committing the generated css files to source control, someone cloning your repo and trying to fix a UI bug would probably just jump into the css file and make the change. They may not know that those files are generated by the .less files.
if she was editing the wrong files, the answer is to do a little more research before diving in.
That's not always as easy as it sounds if a codebase is large, uses non-standard build environments, violates best practices (like unnecessarily checking in generated files, and, if it's really necessary to do so, not making obvious that it's a generated file -- assuming it wasn't a simple oversight on Rachel's part), ...
In my opinion, pull requests should be submitted even if you're not sure they're exactly right as long as you've done a reasonable effort to make it so:
After all, familiarizing yourself with a codebase is done by working with it, and asking for help when you're stuck -- and that's exactly what a pull request is: a request for comments, where you show others what you've done so far. Of course you could have used the mailing list instead, but if there's this nice site available where you can publish your code, which keeps track of changes and provides a commenting and message system, why not make use of it?
I have struggled for a while to get PeepOpen and MacVim working together. I can run :PeepOpen, and it will switch to the running peepopen application, but it doesn't load up with the project files. I've tried all sorts of .vimrc config settings that the internet has to offer, but none worked.
