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

Re: wish: collaboration of N vim instances editing same file

Expand Messages
  • Peter Hodge
    Hello Yakov, Couldn t you hook into the FileChangedShell autocmd event and merge the changes into your buffer from there? You can also handle the swap file
    Message 1 of 7 , Apr 11, 2007
      Hello Yakov,

      Couldn't you hook into the FileChangedShell autocmd event and merge the changes
      into your buffer from there? You can also handle the swap file message with
      SwapExists event.

      regards,
      Peter



      --- Yakov Lerner <iler.ml@...> wrote:

      > Hello Bram,
      > Is it possible to add this item to the vim voting list ?:
      >
      > "collaboration of N vim instances editing same file"
      > -- Ability of N instances of vim to absorb, merge and show changes
      > to the same file made by other running vim instances [ either by reading
      > other vim's swapfiles, or somehow else ] ?
      >
      > Can this be added to SOC ?
      >
      > Yakov
      >


      Send instant messages to your online friends http://au.messenger.yahoo.com
    • Gary Johnson
      ... If you want this collaboration to occur in real time, then I would recommend that you use a screen session in multi-user mode. This solution already
      Message 2 of 7 , Apr 19, 2007
        On 2007-04-11, Yakov Lerner <iler.ml@...> wrote:
        > Hello Bram,
        > Is it possible to add this item to the vim voting list ?:
        >
        > "collaboration of N vim instances editing same file"
        > -- Ability of N instances of vim to absorb, merge and show changes
        > to the same file made by other running vim instances [ either by reading
        > other vim's swapfiles, or somehow else ] ?
        >
        > Can this be added to SOC ?

        If you want this collaboration to occur in real time, then I would
        recommend that you use a screen session in multi-user mode. This
        solution already exists; it works with applications other than vim;
        it avoids complicating the vim code.

        See the screen(1) man page and search for "multi".

        HTH,
        Gary

        --
        Gary Johnson | Agilent Technologies
        garyjohn@... | Mobile Broadband Division
        | Spokane, Washington, USA
      • cga2000
        ... Are you (Is he) talking about several users concurrently modifying the same file(s) .. possibly from different geographic locations? I can t think of any
        Message 3 of 7 , Apr 19, 2007
          On Thu, Apr 19, 2007 at 03:09:38PM EDT, Gary Johnson wrote:
          > On 2007-04-11, Yakov Lerner <iler.ml@...> wrote:
          > > Hello Bram,
          > > Is it possible to add this item to the vim voting list ?:
          > >
          > > "collaboration of N vim instances editing same file"
          > > -- Ability of N instances of vim to absorb, merge and show changes
          > > to the same file made by other running vim instances [ either by reading
          > > other vim's swapfiles, or somehow else ] ?
          > >
          > > Can this be added to SOC ?
          >
          > If you want this collaboration to occur in real time, then I would
          > recommend that you use a screen session in multi-user mode. This
          > solution already exists; it works with applications other than vim;
          > it avoids complicating the vim code.
          >
          > See the screen(1) man page and search for "multi".

          Are you (Is he) talking about several users concurrently modifying the
          same file(s) .. possibly from different geographic locations?

          I can't think of any valid reason why one lonely user - me for instance
          - would want to fire up several instances of vim to edit the same file.

          Or could he be talking about some non-interactive mode .. with possibly
          scripts updating a common file?

          Sorry I hooked up to this particular message .. I no longer have the
          OP's initial message.

          Thanks,
          cga
        • Andrew Maykov
          ... [there was some text] ... It can be. For example, in LNX user can edit file in text console, then switch to X11 and then start editor again to edit the
          Message 4 of 7 , Apr 20, 2007
            On 4/20/07, cga2000 <cga2000@...> wrote:
            > > > "collaboration of N vim instances editing same file"
            [there was some text]
            > > See the screen(1) man page and search for "multi".
            > Are you (Is he) talking about several users concurrently modifying the
            > same file(s) .. possibly from different geographic locations?
            > I can't think of any valid reason why one lonely user - me for instance
            > - would want to fire up several instances of vim to edit the same file.
            It can be. For example, in LNX user can edit file in text console,
            then switch to X11 and then start editor again to edit the same file,
            forgetting that other instance of VIM already launched. I in this case
            just do "killall vim"(or "killall -9 vim", depending on mood).
          • Bram Moolenaar
            ... It s an interesting idea. Won t be easy to implement in such a way that it works on most platforms. It will probably require a server to make it possible
            Message 5 of 7 , Apr 29, 2007
              Yakov Lerner wrote:

              > Is it possible to add this item to the vim voting list ?:
              >
              > "collaboration of N vim instances editing same file"
              > -- Ability of N instances of vim to absorb, merge and show changes
              > to the same file made by other running vim instances [ either by reading
              > other vim's swapfiles, or somehow else ] ?

              It's an interesting idea. Won't be easy to implement in such a way that
              it works on most platforms.

              It will probably require a server to make it possible for various Vim
              instances to find each other. And to take care of authentication.
              Perhaps such a server already exists?

              > Can this be added to SOC ?

              Too late.

              --
              What a wonderfully exciting cough! Do you mind if I join you?
              -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
            • Gregory Seidman
              ... I think the hard part will mostly have to do with design/policy choices. How is a session instigated? Does a single instance own the file and other
              Message 6 of 7 , Apr 29, 2007
                On Sun, Apr 29, 2007 at 10:43:14PM +0200, Bram Moolenaar wrote:
                >
                > Yakov Lerner wrote:
                >
                > > Is it possible to add this item to the vim voting list ?:
                > >
                > > "collaboration of N vim instances editing same file"
                > > -- Ability of N instances of vim to absorb, merge and show changes
                > > to the same file made by other running vim instances [ either by reading
                > > other vim's swapfiles, or somehow else ] ?
                >
                > It's an interesting idea. Won't be easy to implement in such a way that
                > it works on most platforms.

                I think the hard part will mostly have to do with design/policy choices.

                How is a session instigated? Does a single instance "own" the file and
                other instances join? Or maybe there should be some server that fronts a
                repository (e.g. svn, plain filesystem, WebDAV, etc.)? Or does it use svn
                (or WebDAV, or other network fileshare) for everything, including
                discovery, authentication, and inter-vim communication?

                What kind of protocol should be used? It will be at least partially
                homegrown, but is there a standard on which it should be based (perhaps
                there is a standard for recording document edits beyond just diffs, I don't
                know)? Should communication be over a star network of reliable (i.e. TCP)
                connections? A mesh? A hypercube? A minimum spanning tree? Should it be,
                instead, unreliable (i.e. UDP) multicast (which makes discovery easy and
                authentication a separate protocol)?

                None of these questions involve platform-specific issues, since they all
                assume that communication will be over TCP/IP, but I don't think they have
                easy answers. It mostly comes down to what problem you are trying to solve.
                Some sample scenarios:

                - allow a few (<5) open source developers work on the same source file,
                which has its primary existence in a subversion repository to which they
                all have write access, collaboratively across the net

                - allow developers (<5) in the same company work collaboratively on a
                source file over their company LAN

                - allow massive numbers of people collaborate on some literary art project
                (e.g. a collaborative novel, something Wikipedia-like)

                - provide a teleconferencing system for a few writers and a large number of
                readers across the net (e.g. teaching aid, "watch Bram code Vim"
                promotion)

                - two, and only two, developers working together over a fast network

                - allow a small group (<10) collaborators develop the Next Big Thing for
                their startup, despite each developer living in a different city

                Each one implies different choices. If it's over the open net,
                authentication and security are concerns, at least for writers. If
                non-writers are allowed to spectate, you need some sort of permissions
                system. Over the open net there needs to be some handling of timeouts and
                lag. Smaller numbers of participants lets you cut corners in ways that
                larger numbers of participants do not. Editing sensitive data (e.g. the
                next Harry Potter, if J.K. Rowling used Vim and collaborated directly with
                another author or with her editor) requires encryption over the network,
                not to mention strong authentication. Making something that serves all
                these needs is a massive undertaking, but since Vim gets used in all sorts
                of environments, which scenario(s) do you choose?

                > It will probably require a server to make it possible for various Vim
                > instances to find each other. And to take care of authentication.
                > Perhaps such a server already exists?
                [...]

                As far as I know, the first implementation of this sort of idea to gain
                real traction among users of text editors (i.e. largely developers) is
                SubEthaEdit <http://www.codingmonkeys.de/subethaedit/collaborate.html>. It
                uses MacOS X's Bonjour (which is an implementation of ZeroConf, see
                http://developer.apple.com/opensource/internet/bonjour.html for Apple's
                BSD-licensed implementation) for discovery.

                I'd be inclined to go with the single instance owning the file and
                announcing itself via ZeroConf, but I think even that requires either
                requiring a particular ZeroConf implementation on the system or juggling
                carefully which vim instance is responding to DNS requests. It also plays
                no part in authentication.

                Another alternative is to skip discovery and require some out-of-band
                communication (e.g. IM, phone call, etc.) to communicate the host and port
                to connect to. Of course, that makes authentication easy since the same
                out-of-band communication can be used to give a password. No, that isn't
                what you'd call strong authentication or good security, but it's probably
                good enough for most people. Of course, your communication protocol should
                be encrypted...

                Authentication is prickly and I'm not sure how you'd choose what
                authentication methods should be allowed (and implemented). Again, it falls
                under the question of which scenario(s) we intend to serve.

                I'll point out that this sort of thing is what first-person shooter network
                play has been about since Doom first came out way back when. At the time,
                the solution was to broadcast every keystroke (over IPX, yet) and have each
                game instance interpret the keystrokes for the benefit of each virtual
                player. It might be instructive to look into how something like Quake3 does
                things.

                > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                --Greg
              Your message has been successfully submitted and would be delivered to recipients shortly.