| Neovim | Diego Viola | 23.02.14 01:29 | Hi Bram, 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. There's a new project that is called Neovim that seeks to refactor and modernize the codebase, I was interested in knowing what your opinion is on this project? I think many are curious about what you think too. Please let us know. Thanks for Vim. :) http://neovim.org/ Regards, Diego |
| Re: Neovim | Bram Moolenaar | 23.02.14 11:44 | It's going to be an awful lot of work, with the result that not all
systems will be supported, new bugs introduced and what's the gain for the end user exactly? Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users. -- WOMAN: Well, 'ow did you become king then? ARTHUR: The Lady of the Lake, [angels sing] her arm clad in the purest shimmering samite, held aloft Excalibur from the bosom of the water signifying by Divine Providence that I, Arthur, was to carry Excalibur. [singing stops] That is why I am your king! The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// |
| Re: Neovim | Marc Weber | 23.02.14 14:51 | 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'veFor 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 |
| Re: Neovim | Michel Albert | 24.02.14 00:29 | 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. |
| Re: Neovim | Matteo Cavalleri | 24.02.14 00:40 | > 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. that's why Bram wants a test for every patch ;) I don't have the expertise to say which path would be the best for neovim, but at least tests should make refactoring a lot easier. I'm more worried about refactoring the code and, at the same time, change / add stuff (like the new plugin system) |
| Re: Neovim | Jan Larres | 24.02.14 01:29 | Michel Albert <exh...@gmail.com>:
> Partial refactoring is harder (depending on the case, a *lot* harder)The problem with this approach is that everything would still have to go through Bram, which is one of the major hold-ups for many patches that already exist and that arguably improve things. Bram is certainly doing a great job with the time he has available, but he's still a bottleneck as he is only one person. That has led to the todo list getting longer instead of shorter and many patches, including three different approaches for asynchronous processes, just languishing there. So in addition to the refactoring I think that a more flexible development model that is not dependent on just one person and an antiquated 'patches' system could definitely improve things. Jan -- -[ OpenPGP key ID: 00A0FD5F ]- Great minds have purposes, others have wishes. Little minds are tamed and subdued by misfortune; but great minds rise above them. -- Washington Irving |
| Re: Neovim | Max Roeleveld | 24.02.14 02:22 | On Monday, February 24, 2014 10:29:38 AM UTC+1, Jan Larres wrote: > So in That, however, is something that could be done without changing a line of code, right? |
| Re: Neovim | Marc Weber | 24.02.14 04:29 | Vundle vs Vam vs .. issues showed that users don't need 100%
satisfaction in all cases - projects can still be successful. Eg I mean: Vundle depends on vim-scripts.org - and vim-scripts org maps scripts from www.vim.org to urls by title - and some title occur more than once. Thus there is a chance that you cannot install what you want. (There have been 1-2 issues) - still Vundle hase incredibly many users. So the important question is: Which regressions will be critical to masses and which won't? Time will tell. I'm happy that this "experiment" is taking place. If you don't try to succeed - you failed from the beginning IMHO. Marc Weber |
| Re: Neovim | Diego Viola | 24.02.14 08:01 | I don't understand, Bram says "It's much better to improve what we have." which is good and reasonable to me. I agree with this. But then we have people like Thiago de Arruda (aka tarruda) who have worked very hard on multithreading support for Vim, and his patches didn't make it into mainline Vim. So how can we "improve what we have" when 99% of the patches are ignored or rejected according to most developers? Sorry, I do have great respect for Bram Moolenaar and his work, I just don't understand this development model at all. Perhaps the fork could have been avoided if the development model was more reasonable? I don't know. Diego |
| Re: Neovim | Peter Aronoff | 24.02.14 08:34 | On Mon Feb 02/24/14 at 8:01, Diego Viola wrote:I've only been following this list for about a year now, but I can already see that your last paragraph seems unnecessarily negative and the numbers seem pulled from thin air. *99%* of patches are rejected? Really? And *according to most developers*? Really? More realism would help, I think. P -- We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful. Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System |
| Re: Neovim | Diego Viola | 24.02.14 08:36 | OK I'm sorry about that, that was an exaggeration. Sorry. |
| Re: Neovim | LCD 47 | 24.02.14 13:51 | On 24 February 2014, Diego Viola <diego...@gmail.com> wrote:I believe you miss the big picture here. At this point, virtually nobody aside from Bram understands the code well enough to make "big" changes. The other "main" developers are just people that know enough about the code to scratch their own itches. These people post patches occasionally (and Bram usually includes their patches), but their interest is generally limited to particular pieces of Vim, and don't have either the motivation or the resources to look anywhere else. As a result, what happens when an "outsider" posts something as far reaching as the recent timeout / async patch, or the multithreading patch, is that Bram is reluctant to write an in-depth analysis (he has been at this for 20+ years, he has a job, a life, and he already has his hands full just from maintaining Vim as it is), and nobody else really feels qualified to post a meaningful answer. The only somewhat informed feedback the author receives is then a few vague and / or opinionated rants that rarely go beyond pointing out the obvious. Then the author concludes that nobody cares, feels offended, takes it personally, and posts frustrated calls to arms on YC. There, they manage to receive a deluge of way more opinionated, way less informed rants about anything and everything Vim except the actual patch, and things slowly loop back to the statu quo ante. On the other hand, most of these far reaching "outsider" patches are, actually, less than perfect. That's to be expected too, partly because what they are trying to do is objectively hard (if it weren't, it would have been done long ago), and partly because the authors don't read the code end to end before starting to write their patch, to make sure their changes doesn't interact badly with other parts of Vim. That's actually the kind of feedback they would expect from the list. But, as I explained above, this doesn't happen. Rinse and repeat. If you think Bram should just merge all these crowd-acclaimed patches, no question asked, you'd be wrong too (IMO, of course). See f.i. what other people have to say about Vim, even without experimental patches: https://news.ycombinator.com/item?id=6668453 As I see it (and for what it's still worth), the way forward is not to lower the standards for accepting patches. It isn't to rewrite Vim from scratch in Haskell, Javascript, Rust, Go, or whatever other language of the day. It isn't to refactor it to use libuv, or other revolutionary library of the day. And it certainly isn't to compile yet another list of flaws, or another wish list. In my opinion the way forward is for enough people to start reading the code, patiently and diligently, in their own rhythm. Once there is a critical mass of developers who actually understand the code, and see it as just old, rather than terrible or evil, we might see progress. /lcd |
| Re: Neovim | Marc Weber | 24.02.14 14:47 | > In my opinion the way forward is for enough people to start readingWhich will never happen because those people today who want to code might no longer choose C for good reasons (for such a large project) And more than that - starting with Vim',s code base is a huge undertaking. Rule of thumb: Reviewing code takes 50% of the time it took the author to write ! (Which means a lot of time -> nobody can do this in his/her spare time IMHO - without sacrifying family personal goals and the like) Thus its even more important that we try to turn Vim into kind of "business" model - because "specialization" is the engine of todays world - even more for complex software like Vim. Libraries such as libuv just do that: they forward the task of having unique interfaces to a central place - and often its a good idea. I asked in 2010 whether Bram would be willing to spend more time on Vim if he got payed (didn't get a reply that time): reference: https://groups.google.com/forum/#!topic/vim_dev/43b6gsHh4Ok If he had I would have tried starting crowd funding campaigns that time. And that's why I hope that tarruda turns this into a business (for everyone) - so that he (and others) can keep working on their code plugins / parts of vim. Whatever the outcome will be - we'll be smarter afterwards :) What did I learn from the mailinglist recently? The more the merrier. The usual problem is that people have to give up to make a living (eg ensime project), quote from its readme: "A quick note on status: Events in my life have conspired to give me less free time to work on ENSIME." And this is happening to a lot of open source projects (wasting a lot of time of those people who invested some time on such - eg my writing the first ensime frontend for Vim - which I had to give up for time/money reasons, too). What tarruda is doing is the right thing - and I hope that he creates kind of market place for proposals/ people joining them (offering funding) / and programmers saying "for this money I'll get the job done". Then we'll have a healthy community (IMHO). Again - you are free to think differently. I'm pretty sure that tarruda will break a lot of things (by accident). But there is still a chance for paying off in the long run. Marc Weber |
| Re: Neovim | Jan Larres | 24.02.14 15:28 | LCD 47 <lcd...@gmail.com>:
> In my opinion the way forward is for enough people to start readingThis sounds like a good idea in theory, but I don't think Vim's current development model lends itself to that. How do you determine if someome "actually understands" the code? By submitting refactoring patches, or enough patches in general? But several people already have submitted many patches, and many of the needed refactorings, like getting rid of global variables, actually require bigger changes, and Bram would probably be (understandably) reluctant to include them right away. The result of that would be that they just sit in the todo list like so many other patches. I think the best solution to this would be to get rid of the "one branch with patches" model and instead have at least a stable and a development branch, with more people than just Bram being able to commit to the development branch. Bigger changes like refactorings or the new regex engine even could get their own feature branch. That's what VCSs like Mercurial are good at, but it's not being made use of at the moment. With this model the stable branch would be used for releases and by people who care most about stability, and people who are willing to try out new features could use the development branch(es). Unless they disable swap files that shouldn't even be a big risk in general. I'm sure this approach would also motivate more people to contribute when they don't feel like it's a gamble whether their changes will ever actually make it in. -Jan If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. -- Cardinal De Richelieu |
| Re: Neovim | LCD 47 | 24.02.14 15:39 | On 24 February 2014, Marc Weber <marco-...@gmx.de> wrote:
[...] > Thus its even more important that we try to turn Vim into kind ofWhat I'm saying is, it takes _knowledge_ to move forward. Now, some amount of knowledge can be bought (making a business out of your project, hiring people etc.), some other amount can be borrowed (using frameworks, libraries, and the like), and yet some amount can be obtained as a gift (the open source way). However, in my experience most of it has to be earned. It is seldom if ever achieved by spontaneous generation. :) http://en.wikipedia.org/wiki/Spontaneous_generation [...] > What tarruda is doing is the right thing[...] I actually like this project too. I'm just pointing out it's better to think first and then do the work, rather than do the work then find out you should have spent more time thinking first. *shrug* /lcd |
| Re: Neovim | LCD 47 | 24.02.14 16:01 | On 25 February 2014, Jan Larres <li...@majutsushi.net> wrote:[...] You don't. It isn't relevant, the goal is not to give merit bages, but to actually evolve as a group. From this point of view, the process (how the patches are submitted, who gets to say what goes in and when, and so on) are just details. /lcd |
| Re: Neovim | Jan Larres | 24.02.14 16:24 | LCD 47 <lcd...@gmail.com>:
But it's not just details. That's the point. A flexible and transparent development model (transparent as in "people will be able to gauge the success of inclusion of their patches, or at least will receive official feedback in a reasonable amount of time") is crucial for motivating potential contributors. How would your suggested evolving concretely improve things otherwise? People will just magically contribute better patches at some point? Even if that were to happen that would still require Bram to spend time reviewing all of them, so we're back to square one as that is exactly what he doesn't have enough time to do. Like I said, it's a good idea in theory but I don't think it would work out without any other changes. If it could work out something like that would most likely have already happened by now given how long Vim has been around. Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley |
| Re: Neovim | LCD 47 | 24.02.14 22:11 | On 25 February 2014, Jan Larres <li...@majutsushi.net> wrote:[...] I was actually pointing the other direction. If I were more knowledgeable of the code, I would be more inclined and / or able to give meaningful feedback when something like the multithreading patch is posted, rather than shrug it off as outside my comfort zone. Apply that to a number of regulars, and you'd get an actually functioning group. It's only at that point that it would make sense to start talking about improving the process, fork the project, or whatever else you see fit. /lcd |
| Re: Neovim | Jan Larres | 25.02.14 02:53 | The problem is that you need a motivation for investing time in getting
more familiar with the code base. Only very few people would read the code just for fun, in the majority of cases reading code is motivated by wanting to make changes to it. But if the chance of your contributions even getting looked at is very hit-and-miss then that will demotivate even the most engaged person at some point, and they will stop investing time into the code and therefore be lost to the group of people who would be able to give meaningful feedback. One good example apart from the async patch you mentioned that comes to mind is the patch to introduce delete/yank autocommands, which was posted over two years ago and was quite simple, but still hasn't been integrated. The original author has even switched away from Vim now, how much this issue was a part of that I don't know. Faith. n: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. -- Ambrose Bierce, "The Devil's Dictionary" |
| Re: Neovim | Marc Weber | 25.02.14 04:08 | Excerpts from LCD 47's message of Mon Feb 24 23:39:18 +0000 2014:
> I actually like this project too. I'm just pointing out it's betterIf you have suggestions (what to think about first) create issues: https://github.com/neovim/neovim/issues/new We could try to focus on this view: - There is a programmer who got payed to work on Vim - He will work on Vim - Thus there is high chance that soon there will be two people who can review patches in the future - we still can influence what tarruda does - so maybe we should try to do so that his changes can be merged back, too Thus the vim community has two options - ignore - try to collaborate and emphasize on important things Maybe there is a chance to turn this into success for everybody. I'm pretty sure that he'll listen to comments. Important choices: Should neovim build up its own community (mailinglist etc) - or should they be allowed to use vim-dev and vim-use. There is a mailinglist which got added to the README recently. https://groups.google.com/forum/#!forum/neovim Its time to think about this *now*. If there are people on the mailinglist who think they know better than tarruda does - they should talk to him. He is listening. again - my 2 cents Marc Weber |