On Sunday, 23 February 2014 23:51:48 UTC+1, MarcWeber wrote: > Excerpts from Diego Viola's message of Sun Feb 23 09:29:16 +0000 2014: > > > I would like to start by saying that I admire your work on Vim, I've > > > been using it for quite some time now and I really enjoy using Vim > > > every day. > > For a long time quite some things did bother me. They don't affect > > regular users only editing texts. But they do affect programmers who > > want to write fancy extensions. There are "workarounds", such as > > vimproc, vim-addon-async (eg for async communications), but at least the > > -async workaround is a ugly hack. sample features it provides: > > - ruby debugging > > - php debugging > > - ruby/scala/python repl with completion > > I'm not going into details. the wiki link below lists more (please add > > or edit if you think I'm wrong - you can do so) > > > > I personally get annoyed always when not having touched ~/.vimrc and get > > vi instead of vim (without file name completion - I really think such > > things should be fixed - who is using vi behaviour for what reasons? > > > > If you want some vi behaviour it is the time to tell tarruda about what > > you care. > > > > Another simple use case is: :ruby and :py commands cannot be interrupted > > by ctrl-c like (viml) - and the viml implementation is based on gtk > > event loops (gui) which also runs resize viml autocommands arbitrarely. > > > > Of course you can workaround it - but being ablte to abort an infinite > > loop you wrote by accident is helpful - or if a script takes too long > > for whatever reasons. > > > > tarruda will put if_* into separate threads (I hope he'll succeed) - > > and that might fix such small things. > > > > So there are quite a lot of "weak" reasons summing up IMHO. > > > > I've posted about this list earlier: > > http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html > > > > Bram is right: In current state Vim does get most use cases done > > "reasonably well". In fact it would have been me starting such a > > crowd funding project if I would have been satisfied with C/C++ (But I'm > > not). > > > > There are alternatives, eg rust: rust-lang.org - but I'm unsure how > > stable it is at the moment (eg the release doesn't compile the > > rust-csv library at http://www.rust-ci.org/projects/). That's why I > > personally limited myself to writing down what I'd like to change. > > > > For a lot of users neovim might not change too much - but for those who > > want fancy features it could make a big difference - if tarruda gets > > things done the way he described. > > > > Some of you may remember my thread and my page: http://mawercer.de/vim.php > > I forwarded all people to tarruda who either filled in this form or told > > me that they'd assist. So those about 5-7 people will get contacted by > > him hopefully. > > > > Despite all flaws Vim is still the editor of my choice. > > Patching is a lot of work, rewriting would be a lot of work, > > alternatives exist (eg Yi, written in Haskell) - so finding "one true > > upstream" without splitting the community is not simple. > > > > Is it worth the effort? Depends on your use cases - It might be that Vim > > lives as long as the linux kernel - so the future might be even longer > > than its past - who knows? Then it will pay off for sure (IMHO). > > > > Was it the first fork? No, See YZis short description here: > > http://www.freehackers.org/VimIntegration > > (YZis dropped VimL only supporting lua - and most Vimmers depend on a > > lot of viml plugins ..) > > > > I hope that NeoVim will succeed - and that we don't split community too > > much. > > > > Marc Weber
While I agree that there are a couple of things in vim which are annoying, I /think/ (correct me if I'm wrong) Bram was primarily addressing another issue: Total vs Partial refactoring. In my opinion total refactoring is rarely a good idea. The more time and effort went into a project, the riskier it gets. So many years of usage experience went into vim. This means the existing code addresses a vast number of corner cases which crept up during the years. Total refactoring risks an insane amount of regressions. Partial refactoring is harder (depending on the case, a *lot* harder) and will take longer but is not risking as much. And not to forget, has a chance to get merged into the mainline code. The "total refactoring path" is something that pains a lot of the open-source world. It happens so often that an existing project is forked by people who intend to re-write it in a better way. Their intentions are noble. But only few of them succeed. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
