Yes, fortunes. Great. So much better than the async setTimeout patch he's giving a hard time to that will let plugin developers actually build useful tools.
The inanity of the comments in that patch discussion have me reconsidered switching from vim to something else and I've been using vim for nearly ten years. I can't believe how disappointing it's been to see that patch discussion play out as it has.
Asking that timers be identifiable. Can you imagine if setTimeout or setIntervals were user facing in the browser in some kind of list that pops up?
The entire debate about it being async or not. Nobody disputes that JavaScript is an async language, but it only runs in one thread. And here the discussion about it not being really async so it ought to be renamed, is such a silly bikeshed that goes against much of what is considered async in other widespread platforms (JavaScript and ActionScript being notable examples).
The being able to cancel a setTimeout. Imagine users being able to kill asynchronous requests in the browser. Being able to cancel an HTTP request that's modifying the server side database state. Canceling an asynchronous line of execution could create all kinds of unexpected problems, and then exposing that to the user?
The whole being careful thing in itself is insane. You can already create plugins that break shit. You can already create plugins that block. You can already create plugins that rewrite files in the user space and do god knows what harm. That's what comes with exposing a plugin system that isn't sandboxed. And vimscript and the python you can embed in a vimscript is not sandboxed. It's the plugin developer's responsibility to not do stupid shit and the user to not install stupid plugins. And there already are stupid plugins, I've uninstalled some myself.
Actually, users are able to cancel requests on the browser. All they need to do is close the page mid-request. You can try it yourself: write a server that takes 10 seconds to reply to a request, fire an AJAX request for that resource and kill the tab. The request won't make your browser hostage to the server's delay.
And that's where this implementation fails: it makes it possible for a misbehaving 'async' call (not really async, just timed) to hijack the editor and make it unusable. I know that can be done in the editor as-is, but considering that writing asynchronous/multi-threaded code is way harder than your usual linear Vim plugin, I think it's better to wait until there's a proper async mechanism instead of setting a subpar precedent.
> "And that's where this implementation fails: it makes it possible for a misbehaving 'async' call (not really async, just timed) to hijack the editor and make it unusable."
Actually the patch now addresses all of these concerns, you can cancel the setTimeout scripts.
> "but considering that writing asynchronous/multi-threaded code is way harder than your usual linear Vim plugin"
Vim is not thread safe, you can't write a multi-threaded plugin with vim. It will break.
Bikeshedding is about things that really don't matter.
However, something being timed or async do matter. Describing something as async when it's not destroys the meaning of async and confuses what it really does. At the very least, describe it as "blocking async" so it's clear what it is.
Basically, call it what you will, but if you describe it as async, I expect it will be non-blocking because that's what async is by default.
It's the exact same thing that happens in the browser. If you write a setTimeout and never let go, like a never ending while loop it will block your browser forever.
Actually, VIMperator, the VIM-inspired Firefox addon I use, does let me cancel HTTP requests. Even plain Firefox allowed that (with ESC) until a couple of years ago or so.
VIM is an expert's tool, I don't see what's the big problem with allowing users to do potentially dangerous actions.
Ah so using vim makes you an expert eh? Vim's recent popularity seems to be more of these low-skilled node.js gurus who write the meanest package.json description this side of the GitHub jumping on vim as if that would lend them the air of expertise that is actually acquired with a computer science education and considerable experience.
All the Powerline, pretty up my vim "experts" who use vim as means to channel cargo cult style skills into their work is just another reason I've started wanting to stop using vim.
For all the digs at "low skilled gurus", your reasons for choosing -or in this case, leaving- VIM don't seem any less shallow.
In any case, the guy you're disagreeing with is Beam Moolenaar (though I happen to think his arguments aren't that preposterous), and I'm pretty sure he's a vim expert.
https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM
The inanity of the comments in that patch discussion have me reconsidered switching from vim to something else and I've been using vim for nearly ten years. I can't believe how disappointing it's been to see that patch discussion play out as it has.