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

Neovim

Expand Messages
  • Thiago de Arruda
    Some time ago I decided to fork vim to refactor code and implement new features, such as the job control patch. Until yesterday, the plans for this fork
    Message 1 of 7 , Feb 21 9:54 AM
    • 0 Attachment
      Some time ago I decided to fork vim to refactor code and implement new features, such as the job control patch.

      Until yesterday, the plans for this fork existed only in my head, but now everything is documented in github: https://github.com/neovim/neovim . Anyone who likes the ideas is welcome to join :)

      Best regards.

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Anton Bobrov
      ... This is a terrible idea. Only a few plugins can get a benefit. It be a senseless overhead for others. Plugin developers only need an event loop with
      Message 2 of 7 , Feb 21 10:29 PM
      • 0 Attachment
        > New plugin architecture

        > Plugins are long-running programs/jobs (coprocesses) that communicate with vim through stdin/stdout using msgpack-rpc or json-rpc.

        This is a terrible idea. Only a few plugins can get a benefit. It be a senseless overhead for others. Plugin developers only need an event loop with message queue.

        --
        --
        You received this message from the "vim_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • lith
        ... From what I gather, this should enable writing plugins in any language/interpreter, which is a good thing. I just hope NeoVim keeps full compatibility with
        Message 3 of 7 , Feb 22 1:18 AM
        • 0 Attachment
          > > Plugins are long-running programs/jobs (coprocesses)
          >
          > This is a terrible idea. Only a few plugins can get a benefit.

          From what I gather, this should enable writing plugins in any language/interpreter, which is a good thing.

          I just hope NeoVim keeps full compatibility with existing vim plugins.

          --
          --
          You received this message from the "vim_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Christian Brabandt
          ... I am not sure, I like the idea, I have seen too many forks (muttng, cdrkit, ...) that ended up being abandoned, because the work behind it, was
          Message 4 of 7 , Feb 22 4:44 AM
          • 0 Attachment
            On Fr, 21 Feb 2014, Thiago de Arruda wrote:

            > Some time ago I decided to fork vim to refactor code and implement new
            > features, such as the job control patch.
            >
            > Until yesterday, the plans for this fork existed only in my head, but
            > now everything is documented in github:
            > https://github.com/neovim/neovim . Anyone who likes the ideas is
            > welcome to join :)

            I am not sure, I like the idea, I have seen too many forks (muttng,
            cdrkit, ...) that ended up being abandoned, because the work behind it,
            was underestimated.

            What are your plans regarding the development of neovim and its
            compatibility regarding Vim? Will you be following Vims development or
            will Vim and neovim start diverging?

            Best,
            Christian
            --
            I think... I think it's in my basement... Let me go upstairs and check.
            -- Escher

            --
            --
            You received this message from the "vim_use" 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_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • LCD 47
            ... From a quick look at your project, it brings a number of welcome simplifications, but there are also a few design decisions that seem insufficiently
            Message 5 of 7 , Feb 22 8:21 AM
            • 0 Attachment
              On 21 February 2014, Thiago de Arruda <tpadilha84@...> wrote:
              > Some time ago I decided to fork vim to refactor code and implement new
              > features, such as the job control patch.
              >
              > Until yesterday, the plans for this fork existed only
              > in my head, but now everything is documented in github:
              > https://github.com/neovim/neovim . Anyone who likes the ideas is
              > welcome to join :)

              From a quick look at your project, it brings a number of welcome
              simplifications, but there are also a few design decisions that seem
              insufficiently thought out, which are (in my opinion) likely to haunt
              you later.

              > Migrate to a cmake-based build

              Except CMake is a mess in its own right, that adds an otherwise
              pointless dependency of the build process to C++. Probably not a huge
              problem if you only care about gcc and Linux, but a gratuitous pain
              nonetheless. What's wrong with just editing the existing Makefile? You
              only have to do it once.

              > Most of the platform-specific code will be removed and libuv will be
              > used to handle system differences.

              Except libuv is mainly intended for dealing with multiple _network_
              connections. Sure, this might come in handy at some (much later) point,
              but Vim is not I/O-bound. Saying that libuv will handle most of the
              platform differences seems a little naive.

              > Plugins are long-running programs/jobs (coprocesses) that communicate
              > with vim through stdin/stdout using msgpack-rpc or json-rpc.

              As somebody else put it, this is a terrible idea (but for different
              reasons from the ones mentioned there). JSON-RPC over stdio, really?
              Can you tell the difference between network concurrency and IPC
              concurrency? I'd suggest taking a look at how, say, Postfix handles the
              latter, then re-thinking all this approach.

              > GUIs are separate programs, possibly written in different programming
              > languages. Neovim will use its own stdin/stdout to receive input and
              > send updates, again using json-rpc or msgpack-rpc.

              Again, this seems backwards. The reason why Gvim can't do most of
              the tricks Sublime Text does isn't too much integration with the GUI,
              but not enough integration. You might want to spend some more time
              pondering about this approach, too.

              /lcd

              --
              --
              You received this message from the "vim_use" 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_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • ZyX
              ... What?! `eix libuv` describes libuv as “A new platform layer for Node”. Project own README says “libuv is a multi-platform support library with a
              Message 6 of 7 , Feb 22 12:14 PM
              • 0 Attachment
                > Except libuv is mainly intended for dealing with multiple _network_
                > connections. Sure, this might come in handy at some (much later) point,
                > but Vim is not I/O-bound. Saying that libuv will handle most of the
                > platform differences seems a little naive.

                What?! `eix libuv` describes libuv as “A new platform layer for Node”. Project own README says “libuv is a multi-platform support library with a focus on asynchronous I/O.” Where do you see “network” here? Also feature list from this README tells about 12 features, and only two of them are about network.

                --
                --
                You received this message from the "vim_use" 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_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • LCD 47
                ... As far as I can tell, libuv provides exactly what you need to write node-style network servers, and to this day those are still the most spectacular of its
                Message 7 of 7 , Feb 22 1:04 PM
                • 0 Attachment
                  On 22 February 2014, ZyX <zyx.vim@...> wrote:
                  > > Except libuv is mainly intended for dealing with multiple
                  > > _network_ connections. Sure, this might come in handy at some (much
                  > > later) point, but Vim is not I/O-bound. Saying that libuv will
                  > > handle most of the platform differences seems a little naive.
                  >
                  > What?! `eix libuv` describes libuv as ???A new platform layer for
                  > Node???. Project own README says ???libuv is a multi-platform support
                  > library with a focus on asynchronous I/O.??? Where do you see
                  > ???network??? here? Also feature list from this README tells about 12
                  > features, and only two of them are about network.

                  As far as I can tell, libuv provides exactly what you need to write
                  node-style network servers, and to this day those are still the most
                  spectacular of its applications. Can you also use it for something else
                  if you ignore the network features? Sure, since it basically brings
                  libev to Windows, and libev is also supposedly a better libevent. :)

                  Now, _should_ you use libuv as a cross-platform glue if all you care
                  about is (local) IPC, rather than heavily concurrent I/O? Well, maybe
                  not.

                  /lcd

                  --
                  --
                  You received this message from the "vim_use" 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_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+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.