4 ms·

Vim fortunes

6 points by duggieawesome 13y ago

leokun 13y ago
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. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM 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.
- icebraining 13y ago
  Can you point to such inanity? I've only read a couple, but he just seems careful to me.
  - leokun 13y ago
    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. That's the inanity.
    - icebraining 13y ago
      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.
      - leokun 13y ago
        > VIM is an expert's tool 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.
        icebraining 13y ago
        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.
        leokun 13y ago
        Yes I realize, you are right on both. Anyway I haven't given up on vim because it's actually a great editor I've invested a lot of time into.
    - dguaraglia 13y ago
      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.
icebraining 13y ago
Funny, but sheesh, are some of these outdated ;) hundred-and-one symptoms of being an internet addict: 194. Your business cards contain your e-mail and home page address

6 points by duggieawesome 13y ago

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. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM 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.

icebraining 13y ago
Can you point to such inanity? I've only read a couple, but he just seems careful to me.
- leokun 13y ago
  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. That's the inanity.
  - icebraining 13y ago
    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.
    - leokun 13y ago
      > VIM is an expert's tool 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.
      - icebraining 13y ago
        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.
        leokun 13y ago
        Yes I realize, you are right on both. Anyway I haven't given up on vim because it's actually a great editor I've invested a lot of time into.
  - dguaraglia 13y ago
    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.

icebraining 13y ago

Funny, but sheesh, are some of these outdated ;) hundred-and-one symptoms of being an internet addict: 194. Your business cards contain your e-mail and home page address