Nothing, thanks for asking.

I think the point Tarruda's making very effectively is that refactoring can be unnecessarily difficult if your codebase has too much technical debt, too little mechanism for contributing, that this is a barrier to entry, and that at a certain point breaking things and then fixing the important bits while improving the underlying organization, is necessary to maintain forward progress.

Time will tell. The original vi was written by Bill Joy, and is still available as traditional vi. Bram's reimplementation took over because it was more freely available and more feature rich. If Tarruda proves to be a good BDFL, this might be the moment we look back on as the third big fork of vi.

If I'm entering a lot of text, then I'll stay in insert mode, typing away, backspacing to delete and tabbing to indent if auto-indent doesn't do it right. What you're missing is that most software development isn't about entering text. It's about reading existing code to understand the landscape, it's about refactoring code by moving chunks around or renaming things or adding comments here and there, it's about searching and finding, it's about structuring the code or grasping that structure. Unless you're the kind of prodigy who just starts typing and then stops when it's done perfectly the first time, then you're likely doing it too, you're just using the mouse a lot or hitting the cursor keys way more than you have to.

I'm fairly certain that you're doing it wrong.

If the quality of your code matches the quality of your insights here, I feel bad for your employer.

It's worth observing that Bram's vim started as an early 90s reimplementation of vi, which at the time was stuck in legal limbo due to its BSD origins. Vim eventually became the vi of choice for linux distributions, and was lifted by that rising tide to become what everyone now thinks of as vi. The vi that is considered a direct dependent of the original version written by Bill Joy is called "traditional vi".

If in five years, vi is typically a symlink to nvim instead of vim, I will be totally unsurprised.

The root problem here that tarruda is addressing (and he's very explicit about this in the neovim newsgroup) is that the code needs to be refactored for maintainability and to open up the development process. There's one guy in the world who really understands the codebase, so we're all one sleepy bus driver or bursting blood vessel away from vim becoming a frozen pile of code. Tarruda's starting point is refactoring out huge swathes of platform specific code, to be replaced with a single dependency on libuv for cross-platform support, to get to full test coverage, to modernize the C, and to craft a multi-developer process that allows for modern ongoing development by a large number of people, like other OSS projects have.

All the user focussed gains that will flow from that are real gains, but really what Tarruda is doing is freeing Moolenaar from the corner into which he's painted himself. I like to think that Moolenaar (like Stallman with JWZ's fork of emacs) will come around, see the real improvement in the fork, and arrange to cut over to it.

You're doing it wrong... as I was, until someone pointed out that command mode is normal mode. You don't sit in insert mode and jump to command mode, you sit in command mode, manipulating text and moving around, switch into insert mode to add text, and then immediately switch back to command.

Once you get used to doing that, vim suddenly makes a ton more sense, and you start using the keystroke combos to do things much more quickly than before. And the secret to jumping easily from insert to command mode is to add

inoremap jj <ESC>

to your .vimrc. Hit jj quickly when you're done typing, and you're back to normal mode

Leaving the original alone is what tarruda is doing. Do you not understand how forks work?

what's the gain for the end user exactly?

The origin of the fork is that tarunna submitted two large patches to vim that would have fixed a lot of process management in vim, and was rejected because the current vim codebase is so large and crufty that it's impossible to make major architectural changes to it, like allowing for async process management, just because the risk is too high (especially when there's literally one person, Moolenaar, with a commit bit and thus accepting responsility for every change). And the risk really is very high, I'm not faulting Moolenaar for this.

The gain is that (neo)vim will be able to keep up with current technologies in its plugins (like non-blocking operations), it'll allow plugin authors to write faster plugins by speeding up the plugin architecture, existing plugins will see a speed increase, and other programs will be able to embed vim as an editor rather than hacky "vim keybindings" plugins. Given time and asm.js, it'll run natively within a web browser. None of these were in reach with Moolenaar squatting on the code rejecting risky patches. Sounds like a lot of gains to me.

Thanks for the word salad.

If the bill said "Here's more money for you to keep doing the science that you're doing," I'd be perfectly happy with that. If it said "here's money to study only the anthropogenic portion of climate change," I would find that as idiotic as what they did. Any presumption of the conclusion, or restriction on the funding based on their faulty understanding of the field, is idiotic and political.

That said, this particular case has an extra layer of idiocy because the legislature isn't just trying to fund a study to come to its pet conclusion, it's trying to fund a study to come to a rejected minority viewpoint. It's an attack on science itself, trying to force scientists in a particular field to deny their own conclusions because those conclusions are politically troublesome to a certain segment.

To paraphrase you: you "should be taken out and shot". They're already studying "cyclical" climate events as a normal part of studying climate change. They're not ignoring anything. The fact that a legislative body is trying to force them to study something that they're already studying, under a label so hilariously inaccurate as to be useless, is evidence of just two things: 1) they have no fucking clue what they're talking/legislating about; 2) they want "science" backing up the conclusion with which they started.

And 3) you're a useful idiot for them.

The games industry continues to be a shitshow of project management incompetence. Unrealistic deadlines, budgets blown, line workers (i.e., devs in their twenties) death marched... it's like after three decades, they still haven't figured out how to actually make what they make.

What always surprises me is that a very similar model for producing creative content already exists and works really, really well, for the most part. Movies and TV shows deal with comparably large budgets, multiple different yet co-ordinated creative teams, and go through a similar lifecyle of design, execution, post-production, and release. You hear about film productions that go bad largely because it's uncommon for them to do so, and that's virtually always driven by a single figure with excessive influence (e.g., Michael Cimino on Heaven's Gate, Kevin Costner on Waterworld). For the most part, films and TV get made profitably, people get paid, and this is all with a bunch of union labour too. Roles and responsibilities are well-defined; financing models well worked out. They even know how to integrate IP franchises to everyone's benefit.

Why don't Hollywood producers move over to videogames and explain how it works?

Most loss in retail is employee theft. When I worked at a department store, the loss prevention guys were at the doors at closing, letting employees out and checking their bags. When they were patrolling the floor during business hours, they kept a closer eye on employees than on customers. That's just a fact of life no matter what your retail segment is. In fact, I'd bet it's worse for Apple stores because their products are small, easily stolen, and fetch much higher prices than razor blades.

2/3rds of loss in retail is from employee theft. At a place like Apple outlets, where the products are small, expensive, and easily turned over for cash to friends or pawn shops, I'd imagine it's even higher. Not that this fact excuses forcing unpaid overtime on your workers, but I'm not surprised they're doing bag checks.

The sense of adventure in climbing Everest was wounded when they started having traffic jams on the way to the summit, and finally killed when an 80 year old man summited, while being chased by his 81 year old rival. It's a fucking tourist destination now, albeit one that periodically suffers mass casualty events.