Loading ...
Sorry, an error occurred while loading the content.

Neovim

Expand Messages
  • Diego Viola
    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.
    Message 1 of 20 , Feb 23, 2014
    • 0 Attachment
      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/
      https://github.com/neovim/neovim

      Regards,

      Diego

      --
      --
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... 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
      Message 2 of 20 , Feb 23, 2014
      • 0 Attachment
        Diego Viola wrote:

        > 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/
        > https://github.com/neovim/neovim

        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@... -- 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 ///

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        ... 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
        Message 3 of 20 , Feb 23, 2014
        • 0 Attachment
          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

          --
          --
          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Michel Albert
          ... 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:
          Message 4 of 20 , Feb 24, 2014
          • 0 Attachment
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Matteo Cavalleri
            ... 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
            Message 5 of 20 , Feb 24, 2014
            • 0 Attachment
              > 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)

              --
              --
              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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Jan Larres
              ... 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
              Message 6 of 20 , Feb 24, 2014
              • 0 Attachment
                Michel Albert <exhuma@...>:
                > 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 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

                --
                --
                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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Max Roeleveld
                ... That, however, is something that could be done without changing a line of code, right? -- -- You received this message from the vim_dev maillist. Do not
                Message 7 of 20 , Feb 24, 2014
                • 0 Attachment
                  On Monday, February 24, 2014 10:29:38 AM UTC+1, Jan Larres wrote:

                  > 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.

                  That, however, is something that could be done without changing a line of code, right?

                  --
                  --
                  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 vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Marc Weber
                  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
                  Message 8 of 20 , Feb 24, 2014
                  • 0 Attachment
                    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

                    --
                    --
                    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 vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Diego Viola
                    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
                    Message 9 of 20 , Feb 24, 2014
                    • 0 Attachment
                      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

                      --
                      --
                      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 vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Peter Aronoff
                      ... 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
                      Message 10 of 20 , Feb 24, 2014
                      • 0 Attachment
                        On Mon Feb 02/24/14 at 8:01, Diego Viola wrote:
                        > 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?

                        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

                        --
                        --
                        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 vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Diego Viola
                        OK I m sorry about that, that was an exaggeration. Sorry. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below
                        Message 11 of 20 , Feb 24, 2014
                        • 0 Attachment
                          OK I'm sorry about that, that was an exaggeration.

                          Sorry.

                          --
                          --
                          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 vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • LCD 47
                          ... 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
                          Message 12 of 20 , Feb 24, 2014
                          • 0 Attachment
                            On 24 February 2014, Diego Viola <diego.viola@...> wrote:
                            > 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?

                            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.

                            > 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.

                            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

                            --
                            --
                            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 vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • Marc Weber
                            ... Which 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
                            Message 13 of 20 , Feb 24, 2014
                            • 0 Attachment
                              > 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,
                              Which 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

                              --
                              --
                              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 vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Jan Larres
                              ... This 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
                              Message 14 of 20 , Feb 24, 2014
                              • 0 Attachment
                                LCD 47 <lcd047@...>:
                                > 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.

                                This 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

                                --
                                -[ OpenPGP key ID: 00A0FD5F ]-
                                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

                                --
                                --
                                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 vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • LCD 47
                                On 24 February 2014, Marc Weber wrote: [...] ... What I m saying is, it takes _knowledge_ to move forward. Now, some amount of knowledge
                                Message 15 of 20 , Feb 24, 2014
                                • 0 Attachment
                                  On 24 February 2014, Marc Weber <marco-oweber@...> wrote:
                                  [...]
                                  > 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.

                                  What 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

                                  --
                                  --
                                  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 vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • LCD 47
                                  ... [...] 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
                                  Message 16 of 20 , Feb 24, 2014
                                  • 0 Attachment
                                    On 25 February 2014, Jan Larres <lists@...> wrote:
                                    > LCD 47 <lcd047@...>:
                                    > > 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.
                                    >
                                    > This 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?
                                    [...]

                                    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

                                    --
                                    --
                                    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 vim_dev+unsubscribe@....
                                    For more options, visit https://groups.google.com/groups/opt_out.
                                  • Jan Larres
                                    ... 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
                                    Message 17 of 20 , Feb 24, 2014
                                    • 0 Attachment
                                      LCD 47 <lcd047@...>:
                                      > On 25 February 2014, Jan Larres <lists@...> wrote:
                                      >> LCD 47 <lcd047@...>:
                                      >>> 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.
                                      >>
                                      >> This 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?
                                      > [...]
                                      >
                                      > 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.

                                      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.

                                      -Jan

                                      --
                                      -[ OpenPGP key ID: 00A0FD5F ]-
                                      Technological progress has merely provided us with more efficient means for
                                      going backwards.
                                      -- Aldous Huxley

                                      --
                                      --
                                      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 vim_dev+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • LCD 47
                                      ... [...] 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
                                      Message 18 of 20 , Feb 24, 2014
                                      • 0 Attachment
                                        On 25 February 2014, Jan Larres <lists@...> wrote:
                                        > LCD 47 <lcd047@...>:
                                        > > On 25 February 2014, Jan Larres <lists@...> wrote:
                                        > >> LCD 47 <lcd047@...>:
                                        > >>> 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.
                                        > >>
                                        > >> This 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?
                                        > > [...]
                                        > >
                                        > > 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.
                                        >
                                        > 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?
                                        [...]

                                        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

                                        --
                                        --
                                        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 vim_dev+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                      • Jan Larres
                                        ... 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
                                        Message 19 of 20 , Feb 25, 2014
                                        • 0 Attachment
                                          LCD 47 <lcd047@...>:
                                          > On 25 February 2014, Jan Larres <lists@...> wrote:
                                          >> 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?
                                          > [...]
                                          >
                                          > 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.

                                          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.

                                          -Jan

                                          --
                                          -[ OpenPGP key ID: 00A0FD5F ]-
                                          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"

                                          --
                                          --
                                          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 vim_dev+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        • Marc Weber
                                          ... If 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
                                          Message 20 of 20 , Feb 25, 2014
                                          • 0 Attachment
                                            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 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*

                                            If 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

                                            --
                                            --
                                            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 vim_dev+unsubscribe@....
                                            For more options, visit https://groups.google.com/groups/opt_out.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.