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

How to co-editing?

Expand Messages
  • Wu, Yue
    I don t know if it is called co-editing, i.e. serveral men edit the same file at the same time, each modification also shows up on the others vim instand. Is
    Message 1 of 25 , May 28 3:38 PM
    • 0 Attachment
      I don't know if it is called co-editing, i.e. serveral men edit the same file
      at the same time, each modification also shows up on the others' vim instand.

      Is it possible? If so, how to do it?

      --
      Hi,
      Wu, Yue

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tim Chase
      ... I don t believe it s a native ability for Vim. However, I know you can use screen to share shell sessions, which by extension would allow sharing of a
      Message 2 of 25 , May 28 4:50 PM
      • 0 Attachment
        > I don't know if it is called co-editing, i.e. serveral men edit the same file
        > at the same time, each modification also shows up on the others' vim instand.
        >
        > Is it possible? If so, how to do it?

        I don't believe it's a native ability for Vim. However, I know
        you can use "screen" to share shell sessions, which by extension
        would allow sharing of a vim session. However, it's the same vim
        instance, not the editing of disjoint areas of the same file (you
        can't be editing the top of the document while your coworker
        edits the bottom of the file at the same time).

        If you're willing to use asynchronous methods, you can use a
        revision-control system that allows you to merge changes back
        together (i.e. not a "locking" model). That way, each person can
        work on their own local copy (perhaps automatically committing to
        the repository at brief intervals) using their own local OS/Vim
        instance. There are piles of options: Subversion, Mercurial,
        Git, Bazaar, CVS, and Darcs are popular choices[1] (the first 4
        have risen to the top of popular mindshare).

        Lastly, there might be some sort of "concurrent editing" script
        on vim.org or the wiki but I'm not familiar with such.


        If you're trying to teach someone Vim, the screen-sharing may
        work better. If you're just trying to get stuff done in parallel
        on the document, the shared revision-control system is a better
        route, able to keep all edits separate, and provide you with a
        history of who did what. All very handy.

        -tim

        [1]
        http://en.wikipedia.org/wiki/List_of_revision_control_software
        http://en.wikipedia.org/wiki/Comparison_of_revision_control_software





        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_use" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Jack T Mudge III
        ... If you don t mind using a GUI, and if you re in Linux, then you could use Gobby (which does exactly what you re thinking: multiple people simultaneously
        Message 3 of 25 , May 28 7:01 PM
        • 0 Attachment
          On Thursday 28 May 2009 04:50:01 pm Tim Chase wrote:
          > > I don't know if it is called co-editing, i.e. serveral men edit the same
          > > file at the same time, each modification also shows up on the others' vim
          > > instand.
          > >
          > > Is it possible? If so, how to do it?
          >
          > I don't believe it's a native ability for Vim. However, I know
          > you can use "screen" to share shell sessions, which by extension
          > would allow sharing of a vim session. However, it's the same vim
          > instance, not the editing of disjoint areas of the same file (you
          > can't be editing the top of the document while your coworker
          > edits the bottom of the file at the same time).
          >
          > If you're willing to use asynchronous methods, you can use a
          > revision-control system that allows you to merge changes back
          > together (i.e. not a "locking" model). That way, each person can
          > work on their own local copy (perhaps automatically committing to
          > the repository at brief intervals) using their own local OS/Vim
          > instance. There are piles of options: Subversion, Mercurial,
          > Git, Bazaar, CVS, and Darcs are popular choices[1] (the first 4
          > have risen to the top of popular mindshare).
          >
          > Lastly, there might be some sort of "concurrent editing" script
          > on vim.org or the wiki but I'm not familiar with such.
          >
          >
          > If you're trying to teach someone Vim, the screen-sharing may
          > work better. If you're just trying to get stuff done in parallel
          > on the document, the shared revision-control system is a better
          > route, able to keep all edits separate, and provide you with a
          > history of who did what. All very handy.
          >
          > -tim
          >
          > [1]
          > http://en.wikipedia.org/wiki/List_of_revision_control_software
          > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software


          If you don't mind using a GUI, and if you're in Linux, then you could use Gobby (which does exactly what you're thinking: multiple people simultaneously editing the same file).


          I don't know of an equivalent on the console or through Vim, alas.


          Hope it helps!


          --
          Sincerely,
          Jack Mudge
          jakykong@...
        • Raúl Núñez de Arenas Coronado
          Saluton Yue :) ... I don t know your exact needs, so maybe this answer is just a bunch of off-topic material, but in my almost-humble opinion, your best bet is
          Message 4 of 25 , May 29 1:13 PM
          • 0 Attachment
            Saluton Yue :)

            On Fri 29 May 2009 00:38, Wu +0200, Yue <v...@...> dixit:
            > I don't know if it is called co-editing, i.e. serveral men edit the
            > same file at the same time, each modification also shows up on the
            > others' vim instand.
            >
            > Is it possible? If so, how to do it?

            I don't know your exact needs, so maybe this answer is just a bunch of
            off-topic material, but in my almost-humble opinion, your best bet is to
            use a revision control system. For, let's say, "concurrent" editing, it
            is the best way to go, because it has a whole lot of advantages over
            just edit the same file at the same file using some capability of some
            editor.

            If you could elaborate your needs a bit more, maybe I could give you a
            better answer, but please note that it will probably along the same
            lines: use a revision control system. My favourite is Bazaar, but
            subversion or Git are really good, too. Heck, even CVS is better than
            nothing ;)

            --
            Raúl "DervishD" Núñez de Arenas Coronado
            Linux Registered User 88736 | http://www.dervishd.net
            It's my PC and I'll cry if I want to... RAmen!

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_use" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Ben Fritz
            I d like to point out this item in the feature list being voted on by Vim sponsors: add collaborative editing: changes made to a buffer show up in another Vim
            Message 5 of 25 , May 29 1:23 PM
            • 0 Attachment
              I'd like to point out this item in the feature list being voted on by
              Vim sponsors:

              "add collaborative editing: changes made to a buffer show up in
              another Vim in a second"
              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_use" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Wu, Yue
              Thanks all for useful infos! Now I know the vcs is the best choice at this time, but it still can t show the changes dynamically, anyway, it s a solution. --
              Message 6 of 25 , May 29 5:43 PM
              • 0 Attachment
                Thanks all for useful infos! Now I know the vcs is the best choice at this
                time, but it still can't show the changes dynamically, anyway, it's a
                solution.

                --
                Hi,
                Wu, Yue

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_use" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Raúl Núñez de Arenas Coronado
                Saluton Yue :) ... VCS s are not at all about showing the changes dynamically. In fact that s a usage pattern very uncommon for collaborative development,
                Message 7 of 25 , May 30 9:42 AM
                • 0 Attachment
                  Saluton Yue :)

                  On Sat 30 May 2009 02:43, Wu +0200, Yue <v...@...> dixit:
                  > Thanks all for useful infos! Now I know the vcs is the best choice at
                  > this time, but it still can't show the changes dynamically, anyway,
                  > it's a solution.

                  VCS's are not at all about showing the changes dynamically. In fact
                  that's a usage pattern very uncommon for collaborative development,
                  where you concentrate on *your* set of changes and the rest of
                  developers in *theirs* and then everyone commits the changes and the VCS
                  does the dirty job of putting everything together.

                  If you think you need to show the changes dynamically (and
                  instantaneously, I assume), maybe VCS's are not the way to go, but on
                  the other hand maybe you should think again about your needs about how
                  to solve your problem.

                  Again, if you could elaborate a bit more about your particular problem,
                  we would be more proficient giving you help. I understand that maybe you
                  cannot reveal details (if this is for some job, for example), but if you
                  can, tell us and probably we will be able to help better :)

                  Good luck anyway :)

                  --
                  Raúl "DervishD" Núñez de Arenas Coronado
                  Linux Registered User 88736 | http://www.dervishd.net
                  It's my PC and I'll cry if I want to... RAmen!

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_use" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Wu, Yue
                  ... For example, if I m editing a file, and the file has been modified by external tool, say echo foo file, since the last time I haved saved, then now
                  Message 8 of 25 , May 30 5:07 PM
                  • 0 Attachment
                    On Sat, May 30, 2009 at 06:42:17PM +0200, Raúl Núñez de Arenas Coronado wrote:
                    >
                    > Saluton Yue :)
                    >
                    > On Sat 30 May 2009 02:43, Wu +0200, Yue <v...@...> dixit:
                    > > Thanks all for useful infos! Now I know the vcs is the best choice at
                    > > this time, but it still can't show the changes dynamically, anyway,
                    > > it's a solution.
                    >
                    > VCS's are not at all about showing the changes dynamically. In fact
                    > that's a usage pattern very uncommon for collaborative development,
                    > where you concentrate on *your* set of changes and the rest of
                    > developers in *theirs* and then everyone commits the changes and the VCS
                    > does the dirty job of putting everything together.
                    >
                    > If you think you need to show the changes dynamically (and
                    > instantaneously, I assume), maybe VCS's are not the way to go, but on
                    > the other hand maybe you should think again about your needs about how
                    > to solve your problem.
                    >
                    > Again, if you could elaborate a bit more about your particular problem,
                    > we would be more proficient giving you help. I understand that maybe you
                    > cannot reveal details (if this is for some job, for example), but if you
                    > can, tell us and probably we will be able to help better :)
                    >
                    > Good luck anyway :)

                    For example, if I'm editing a file, and the file has been modified by external
                    tool, say echo foo >> file, since the last time I haved saved, then now after
                    I'm finishing the editings and want to write the file to disk, then vim will
                    warn that file has been changed, what should I do? 1) Abandon my editing; 2)
                    Abandon the changes by external tool. Both of them are not so good.

                    --
                    Hi,
                    Wu, Yue

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_use" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Tim Chase
                    ... If something has changed the file that I m currently editing (such as a parallel edit session or a automated script), I ll ... (assuming only two windows
                    Message 9 of 25 , May 30 6:22 PM
                    • 0 Attachment
                      > For example, if I'm editing a file, and the file has been
                      > modified by external tool, say echo foo >> file, since the
                      > last time I haved saved, then now after I'm finishing the
                      > editings and want to write the file to disk, then vim will
                      > warn that file has been changed, what should I do? 1) Abandon
                      > my editing; 2) Abandon the changes by external tool. Both of
                      > them are not so good.

                      If something has changed the file that I'm currently editing
                      (such as a parallel edit session or a automated script), I'll
                      often yank my buffer into a new one:

                      :%y
                      :new
                      :0put
                      :$d

                      then switch back to my original buffer and reload it:

                      :e!

                      and compare the two buffers:

                      :windo diffthis

                      (assuming only two windows are open...otherwise, visit each one
                      and ":diffthis" on it.)

                      This allows me to get/put differences in the files. If it was
                      something that happened frequently, I'd likely create a few
                      mappings to facilitate it. Or perhaps the "DiffOrig" command
                      (":help DiffOrig") instead.

                      -tim




                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_use" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Wu, Yue
                      ... But when you re diffing them, buffer may has changed from external again, so the diff can be messed up. I realize it s complicated to achieve it, it has to
                      Message 10 of 25 , May 30 7:52 PM
                      • 0 Attachment
                        On Sat, May 30, 2009 at 08:22:58PM -0500, Tim Chase wrote:
                        >
                        > > For example, if I'm editing a file, and the file has been
                        > > modified by external tool, say echo foo >> file, since the
                        > > last time I haved saved, then now after I'm finishing the
                        > > editings and want to write the file to disk, then vim will
                        > > warn that file has been changed, what should I do? 1) Abandon
                        > > my editing; 2) Abandon the changes by external tool. Both of
                        > > them are not so good.
                        >
                        > If something has changed the file that I'm currently editing
                        > (such as a parallel edit session or a automated script), I'll
                        > often yank my buffer into a new one:
                        >
                        > :%y
                        > :new
                        > :0put
                        > :$d
                        >
                        > then switch back to my original buffer and reload it:
                        >
                        > :e!
                        >
                        > and compare the two buffers:
                        >
                        > :windo diffthis
                        >
                        > (assuming only two windows are open...otherwise, visit each one
                        > and ":diffthis" on it.)
                        >
                        > This allows me to get/put differences in the files. If it was
                        > something that happened frequently, I'd likely create a few
                        > mappings to facilitate it. Or perhaps the "DiffOrig" command
                        > (":help DiffOrig") instead.

                        But when you're diffing them, buffer may has changed from external again, so
                        the diff can be messed up. I realize it's complicated to achieve it, it has to
                        make vim edit the file in disk, not in mem's one, so the dynamic change can be
                        seen on the fly.

                        The example I gave is not quit good, it can be soloved by vcs. Sorry, I give a
                        more proper example here: if I'm editing one file with other guy, and want to
                        let him adds some lines in the file, and let me revise it, then the co-editing
                        is much more convenient. I heard of that M$ office supports co-edit, don't
                        know how it supports that.

                        --
                        Hi,
                        Wu, Yue

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_use" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • bill lam
                        ... IIUC, you want it implemented like a multi-player online game. -- regards, ==================================================== GPG key 1024D/4434BAB3
                        Message 11 of 25 , May 30 8:04 PM
                        • 0 Attachment
                          On Sun, 31 May 2009, Wu, Yue wrote:
                          >
                          > On Sat, May 30, 2009 at 08:22:58PM -0500, Tim Chase wrote:
                          > >
                          > > > For example, if I'm editing a file, and the file has been
                          > > > modified by external tool, say echo foo >> file, since the
                          > > > last time I haved saved, then now after I'm finishing the
                          > > > editings and want to write the file to disk, then vim will
                          > > > warn that file has been changed, what should I do? 1) Abandon
                          > > > my editing; 2) Abandon the changes by external tool. Both of
                          > > > them are not so good.
                          > >
                          > > If something has changed the file that I'm currently editing
                          > > (such as a parallel edit session or a automated script), I'll
                          > > often yank my buffer into a new one:
                          > >
                          > > :%y
                          > > :new
                          > > :0put
                          > > :$d
                          > >
                          > > then switch back to my original buffer and reload it:
                          > >
                          > > :e!
                          > >
                          > > and compare the two buffers:
                          > >
                          > > :windo diffthis
                          > >
                          > > (assuming only two windows are open...otherwise, visit each one
                          > > and ":diffthis" on it.)
                          > >
                          > > This allows me to get/put differences in the files. If it was
                          > > something that happened frequently, I'd likely create a few
                          > > mappings to facilitate it. Or perhaps the "DiffOrig" command
                          > > (":help DiffOrig") instead.
                          >
                          > But when you're diffing them, buffer may has changed from external again, so
                          > the diff can be messed up. I realize it's complicated to achieve it, it has to
                          > make vim edit the file in disk, not in mem's one, so the dynamic change can be
                          > seen on the fly.
                          >
                          > The example I gave is not quit good, it can be soloved by vcs. Sorry, I give a
                          > more proper example here: if I'm editing one file with other guy, and want to
                          > let him adds some lines in the file, and let me revise it, then the co-editing
                          > is much more convenient. I heard of that M$ office supports co-edit, don't
                          > know how it supports that.

                          IIUC, you want it implemented like a multi-player online game.

                          --
                          regards,
                          ====================================================
                          GPG key 1024D/4434BAB3 2008-08-24
                          gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
                          唐詩093 駱賓王 在獄詠蟬
                          西路蟬聲唱 南冠客思侵 那堪玄鬢影 來對白頭吟
                          露重飛難進 風多響易沉 無人信高潔 誰為表予心

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_use" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • pansz
                          ... This is the scenario we ve encountered everyday, and we use subversion. When somebody has done some modification and want me to revise, he simply svn
                          Message 12 of 25 , May 30 8:38 PM
                          • 0 Attachment
                            Wu, Yue 写道:
                            > The example I gave is not quit good, it can be soloved by vcs. Sorry, I give a
                            > more proper example here: if I'm editing one file with other guy, and want to
                            > let him adds some lines in the file, and let me revise it, then the co-editing
                            > is much more convenient. I heard of that M$ office supports co-edit, don't
                            > know how it supports that.
                            >

                            This is the scenario we've encountered everyday, and we use subversion.

                            When somebody has done some modification and want me to revise, he
                            simply "svn commit" the change, and I can do "svn update" to see what he
                            has changed. It is better for me, since I want every change be in the
                            revision history, even if I may revert his modification.

                            Documents are better handled that way since every change are expected to
                            be recorded.

                            Or if all you want is a "shared whiteboard or blackboard", netmeeting
                            can do that.

                            Or if all you want is to edit the same document, simply share the same
                            computer, i.e. hot-seat mode. believe me, if the work must be revised
                            *immediately*, hot-seat won't waste too much time. if not, VCS is better.


                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_use" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Wu, Yue
                            ... Thanks for providing so many options, I think I need a netmeeting or hot-seat mode thing :) -- Hi, Wu, Yue
                            Message 13 of 25 , May 31 5:29 AM
                            • 0 Attachment
                              On Sun, May 31, 2009 at 11:38:25AM +0800, pansz wrote:
                              >
                              > Wu, Yue 写道:
                              > > The example I gave is not quit good, it can be soloved by vcs. Sorry, I give a
                              > > more proper example here: if I'm editing one file with other guy, and want to
                              > > let him adds some lines in the file, and let me revise it, then the co-editing
                              > > is much more convenient. I heard of that M$ office supports co-edit, don't
                              > > know how it supports that.
                              > >
                              >
                              > This is the scenario we've encountered everyday, and we use subversion.
                              >
                              > When somebody has done some modification and want me to revise, he
                              > simply "svn commit" the change, and I can do "svn update" to see what he
                              > has changed. It is better for me, since I want every change be in the
                              > revision history, even if I may revert his modification.
                              >
                              > Documents are better handled that way since every change are expected to
                              > be recorded.
                              >
                              > Or if all you want is a "shared whiteboard or blackboard", netmeeting
                              > can do that.
                              >
                              > Or if all you want is to edit the same document, simply share the same
                              > computer, i.e. hot-seat mode. believe me, if the work must be revised
                              > *immediately*, hot-seat won't waste too much time. if not, VCS is better.

                              Thanks for providing so many options, I think I need a netmeeting or hot-seat
                              mode thing :)

                              --
                              Hi,
                              Wu, Yue

                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_use" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Raúl Núñez de Arenas Coronado
                              Saluton Yue :) ... What I don t understand is why do you need to do things that way. I mean, why your file may be modified by external tools or why another
                              Message 14 of 25 , May 31 11:54 PM
                              • 0 Attachment
                                Saluton Yue :)

                                On Sun 31 May 2009 02:07, Wu +0200, Yue <v...@...> dixit:
                                > On Sat, May 30, 2009 at 06:42:17PM +0200, Raúl Núñez de Arenas
                                > Coronado wrote:
                                >> If you think you need to show the changes dynamically (and
                                >> instantaneously, I assume), maybe VCS's are not the way to go, but on
                                >> the other hand maybe you should think again about your needs about
                                >> how to solve your problem.
                                >>
                                >> Again, if you could elaborate a bit more about your particular
                                >> problem, we would be more proficient giving you help. I understand
                                >> that maybe you cannot reveal details (if this is for some job, for
                                >> example), but if you can, tell us and probably we will be able to
                                >> help better :)
                                >
                                > For example, if I'm editing a file, and the file has been modified by
                                > external tool, say echo foo >> file, since the last time I haved
                                > saved, then now after I'm finishing the editings and want to write the
                                > file to disk, then vim will warn that file has been changed, what
                                > should I do? 1) Abandon my editing; 2) Abandon the changes by external
                                > tool. Both of them are not so good.

                                What I don't understand is why do you need to do things that way. I
                                mean, why your file may be modified by external tools or why another
                                person has to edit the same copy of the file you are editing too.

                                If both you and your coworkers need to edit the same files because
                                everybody is working in *different* parts of them (for example, when
                                doing collaborative development) then VCS is the best solution. Each
                                person has his own copy of the data and from time to time all of them do
                                commits, merges are performed, etc.

                                If the problem is that you have some files that anyone may edit at any
                                point in time, you actually *DO NEED* to see the changes other are
                                making in their copies and show them on YOUR copy. There is no easy
                                solution to this problem, specially on UNIX, because it is a very
                                dangerous thing to do.

                                In this case and in my humble opinion, you need a change in the way you
                                work to avoid having to modify files concurrently. It is dangerous
                                unless *everybody* uses the same tool for modifying the files *and* that
                                tool has been designed for such job (concurrent editing). I've read the
                                other messages you've written about the issue and from my point of view
                                the problem is that you shouldn't be doing concurrent edition ;)) If you
                                have to do it (we can't always choose how to work, unfortunately), look
                                for a tool designed to do concurrent edition or sooner or later you will
                                get a nasty surprise: lost data. If you want me to I can explain what
                                kind of data losing you may suffer, but I'll do in a private email
                                because that would be offtopic :)

                                --
                                Raúl "DervishD" Núñez de Arenas Coronado
                                Linux Registered User 88736 | http://www.dervishd.net
                                It's my PC and I'll cry if I want to... RAmen!

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_use" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Wu, Yue
                                ... Yes, after many kind of help and advice, I realize I m trying to do something in a wrong way, it s dangerous. But what about in this case: I want to share
                                Message 15 of 25 , Jun 1, 2009
                                • 0 Attachment
                                  On Mon, Jun 01, 2009 at 08:54:34AM +0200, Raúl Núñez de Arenas Coronado wrote:
                                  >
                                  > What I don't understand is why do you need to do things that way. I
                                  > mean, why your file may be modified by external tools or why another
                                  > person has to edit the same copy of the file you are editing too.
                                  >
                                  > If both you and your coworkers need to edit the same files because
                                  > everybody is working in *different* parts of them (for example, when
                                  > doing collaborative development) then VCS is the best solution. Each
                                  > person has his own copy of the data and from time to time all of them do
                                  > commits, merges are performed, etc.
                                  >
                                  > If the problem is that you have some files that anyone may edit at any
                                  > point in time, you actually *DO NEED* to see the changes other are
                                  > making in their copies and show them on YOUR copy. There is no easy
                                  > solution to this problem, specially on UNIX, because it is a very
                                  > dangerous thing to do.
                                  >
                                  > In this case and in my humble opinion, you need a change in the way you
                                  > work to avoid having to modify files concurrently. It is dangerous
                                  > unless *everybody* uses the same tool for modifying the files *and* that
                                  > tool has been designed for such job (concurrent editing). I've read the
                                  > other messages you've written about the issue and from my point of view
                                  > the problem is that you shouldn't be doing concurrent edition ;)) If you
                                  > have to do it (we can't always choose how to work, unfortunately), look
                                  > for a tool designed to do concurrent edition or sooner or later you will
                                  > get a nasty surprise: lost data. If you want me to I can explain what
                                  > kind of data losing you may suffer, but I'll do in a private email
                                  > because that would be offtopic :)

                                  Yes, after many kind of help and advice, I realize I'm trying to do something
                                  in a wrong way, it's dangerous.

                                  But what about in this case: I want to share a file with others and we can
                                  edit one same file, so it can act like that we are chatting via this file, and
                                  when I'm typing something, then others typing will show up dranamically, I
                                  think it's a case of concurrent editing, hmm? Someone advices me the
                                  netmeeting, I don't know if he says the Microsoft's apps, but maybe that's the
                                  right tool for doing such thing. I'm a vim fans, maybe I'm trying to do
                                  something that has extently exceeded vim's ability.

                                  --
                                  Hi,
                                  Wu, Yue

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_use" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Raúl Núñez de Arenas Coronado
                                  Saluton Yue :) ... It s dangerous only if you don t use the appropriate tools, and only if more than one person can write the file at any given point in time.
                                  Message 16 of 25 , Jun 1, 2009
                                  • 0 Attachment
                                    Saluton Yue :)

                                    On Mon 1 Jun 2009 13:39, Wu +0200, Yue <v...@...> dixit:
                                    > On Mon, Jun 01, 2009 at 08:54:34AM +0200, Raúl Núñez de Arenas
                                    > Coronado wrote:
                                    >> In this case and in my humble opinion, you need a change in the way
                                    >> you work to avoid having to modify files concurrently. It is
                                    >> dangerous unless *everybody* uses the same tool for modifying the
                                    >> files *and* that tool has been designed for such job (concurrent
                                    >> editing). I've read the other messages you've written about the issue
                                    >> and from my point of view the problem is that you shouldn't be doing
                                    >> concurrent edition ;)) If you have to do it (we can't always choose
                                    >> how to work, unfortunately), look for a tool designed to do
                                    >> concurrent edition or sooner or later you will get a nasty surprise:
                                    >> lost data. If you want me to I can explain what kind of data losing
                                    >> you may suffer, but I'll do in a private email because that would be
                                    >> offtopic :)
                                    >
                                    > Yes, after many kind of help and advice, I realize I'm trying to do
                                    > something in a wrong way, it's dangerous.

                                    It's dangerous only if you don't use the appropriate tools, and only if
                                    more than one person can write the file at any given point in time.

                                    > But what about in this case: I want to share a file with others and we
                                    > can edit one same file, so it can act like that we are chatting via
                                    > this file, and when I'm typing something, then others typing will show
                                    > up dranamically, I think it's a case of concurrent editing, hmm?

                                    I understand the example, but in that case I would use a chat program ;)
                                    Anyway, I understand your point: if you need to do the concurrent
                                    editing, you need it, period. In that case I think it is safer if you
                                    use a tool that supports concurrent editing instead of tweaking Vim to
                                    do the job (which may be possible).

                                    > Someone advices me the netmeeting, I don't know if he says the
                                    > Microsoft's apps, but maybe that's the right tool for doing such
                                    > thing. I'm a vim fans, maybe I'm trying to do something that has
                                    > extently exceeded vim's ability.

                                    I think you could write some autocommands for CursorHold, CursorHoldI,
                                    CursorMove and CursorMoveI so that if the file is changed you reload it,
                                    but that way the changes you made are lost. Mixing your changes and the
                                    changes from other people is possible by using "diff" or "diff3" when
                                    reloading the file.

                                    Under Linux you can use inotify to check if someone wrote to the file
                                    and the reload it, but right now I don't know how to use that to force
                                    the rest of Vim processes to reload and merge the file.

                                    Please note that no matter if you use an inotify-based solution or some
                                    autocommands to monitor the file and reload+merge it, this is very error
                                    prone and problems will happen as soon as two writers make incompatible
                                    changes (both of them modify the exact same line, for example).

                                    Your problem has no easy solution using Vim, because the only way you
                                    could use Vim for what you want to do is to have just ONE Vim instance
                                    acting as "server", and that instance is the only with physical access
                                    to the concurrently-edited file. After that, each person editing the
                                    file just uses a "client" Vim that sends keystrokes to the server. The
                                    server performs the actions from all clients and updates all of them
                                    with the new file contents. This is not concurrent at all, because the
                                    actions from the clients are serialized, but it is collaborative,
                                    changes are shown automatically, etc. The only problem with this
                                    solution is that, as far as I know, you can set up a Vim server editing
                                    a file and accepting keystrokes from clients, but you cannot set up a
                                    "client" Vim that sends all the keystrokes to the server and receives
                                    the updated file contents. The only way I know of sending keystrokes to
                                    a "server" Vim is to use "--remote-send".

                                    --
                                    Raúl "DervishD" Núñez de Arenas Coronado
                                    Linux Registered User 88736 | http://www.dervishd.net
                                    It's my PC and I'll cry if I want to... RAmen!

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_use" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • Gary Johnson
                                    ... For that particular case, I think you should try screen, as Tim suggested earlier. As I understand it, in multiuser mode, screen passes all the keyboard
                                    Message 17 of 25 , Jun 1, 2009
                                    • 0 Attachment
                                      On 2009-06-01, Wu, Yue wrote:

                                      > But what about in this case: I want to share a file with others
                                      > and we can edit one same file, so it can act like that we are
                                      > chatting via this file, and when I'm typing something, then others
                                      > typing will show up dranamically, I think it's a case of
                                      > concurrent editing, hmm? Someone advices me the netmeeting, I
                                      > don't know if he says the Microsoft's apps, but maybe that's the
                                      > right tool for doing such thing. I'm a vim fans, maybe I'm trying
                                      > to do something that has extently exceeded vim's ability.

                                      For that particular case, I think you should try screen, as Tim
                                      suggested earlier. As I understand it, in multiuser mode, screen
                                      passes all the keyboard inputs from all connected users to the
                                      application. Take a look at the screen man page, or the home page
                                      at http://www.gnu.org/software/screen/screen.html. A Google search
                                      for "gnu screen multiuser" turns up a lot of useful-looking hits.

                                      Regards,
                                      Gary



                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_use" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    • Jason Axelson
                                      ... Also note that if you can login via the same shell account you don t have to use screen s multiuser mode, simply run screen -x Regards, Jason
                                      Message 18 of 25 , Jun 1, 2009
                                      • 0 Attachment
                                        On Mon, Jun 1, 2009 at 8:37 AM, Gary Johnson <garyjohn@...> wrote:
                                        > For that particular case, I think you should try screen, as Tim
                                        > suggested earlier.  As I understand it, in multiuser mode, screen
                                        > passes all the keyboard inputs from all connected users to the
                                        > application.  Take a look at the screen man page, or the home page
                                        > at http://www.gnu.org/software/screen/screen.html.  A Google search
                                        > for "gnu screen multiuser" turns up a lot of useful-looking hits.

                                        Also note that if you can login via the same shell account you don't
                                        have to use screen's multiuser mode, simply run screen -x

                                        Regards,
                                        Jason

                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_use" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • Wu, Yue
                                        ... Hi, man, really thank you for so patient help and advicing! I d better find a right tool for my purpose, it s wrong to make vim to be an OS :) -- Hi, Wu,
                                        Message 19 of 25 , Jun 1, 2009
                                        • 0 Attachment
                                          On Mon, Jun 01, 2009 at 07:14:18PM +0200, Raúl Núñez de Arenas Coronado wrote:
                                          >
                                          > Please note that no matter if you use an inotify-based solution or some
                                          > autocommands to monitor the file and reload+merge it, this is very error
                                          > prone and problems will happen as soon as two writers make incompatible
                                          > changes (both of them modify the exact same line, for example).
                                          >
                                          > Your problem has no easy solution using Vim, because the only way you
                                          > could use Vim for what you want to do is to have just ONE Vim instance
                                          > acting as "server", and that instance is the only with physical access
                                          > to the concurrently-edited file. After that, each person editing the
                                          > file just uses a "client" Vim that sends keystrokes to the server. The
                                          > server performs the actions from all clients and updates all of them
                                          > with the new file contents. This is not concurrent at all, because the
                                          > actions from the clients are serialized, but it is collaborative,
                                          > changes are shown automatically, etc. The only problem with this
                                          > solution is that, as far as I know, you can set up a Vim server editing
                                          > a file and accepting keystrokes from clients, but you cannot set up a
                                          > "client" Vim that sends all the keystrokes to the server and receives
                                          > the updated file contents. The only way I know of sending keystrokes to
                                          > a "server" Vim is to use "--remote-send".

                                          Hi, man, really thank you for so patient help and advicing! I'd better find a
                                          right tool for my purpose, it's wrong to make vim to be an OS :)

                                          --
                                          Hi,
                                          Wu, Yue

                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_use" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • Raúl Núñez de Arenas Coronado
                                          Saluton Yue :) ... XDDDDD Yes, after using Vim for a month or so and discovering how configurable and adaptable (and powerful...), one tends to use Vim for all
                                          Message 20 of 25 , Jun 1, 2009
                                          • 0 Attachment
                                            Saluton Yue :)

                                            On Tue 2 Jun 2009 02:39, Wu +0200, Yue <v...@...> dixit:
                                            > Hi, man, really thank you for so patient help and advicing! I'd better
                                            > find a right tool for my purpose, it's wrong to make vim to be an OS
                                            > :)

                                            XDDDDD Yes, after using Vim for a month or so and discovering how
                                            configurable and adaptable (and powerful...), one tends to use Vim for
                                            all kind of things and thinks about using Vim for a wide set of duties.
                                            I think it is usual to have the desire of using the program we love for
                                            each and every daily task :)

                                            --
                                            Raúl "DervishD" Núñez de Arenas Coronado
                                            Linux Registered User 88736 | http://www.dervishd.net
                                            It's my PC and I'll cry if I want to... RAmen!

                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_use" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • Teemu Likonen
                                            ... The Emacs operating system has several ways for collaborative editing: http://www.emacswiki.org/emacs/CollaborativeEditing It seems that some people are
                                            Message 21 of 25 , Jun 2, 2009
                                            • 0 Attachment
                                              On 2009-06-02 08:39 (+0800), Wu, Yue wrote:

                                              > Hi, man, really thank you for so patient help and advicing! I'd better
                                              > find a right tool for my purpose, it's wrong to make vim to be an OS
                                              > :)

                                              The Emacs operating system has several ways for collaborative editing:

                                              http://www.emacswiki.org/emacs/CollaborativeEditing

                                              It seems that some people are developing Obby protocol support for Emacs
                                              but it's not ready yet.

                                              But there is also a D-Bus-based system which allows users of Vim, Emacs
                                              and Gedit to edit the same document. For more info:

                                              http://alban.apinc.org/blog/collaborative-editing/

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_use" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • pansz
                                              ... I know what you want is a shared blackboard. For this use I recommend GNU Screen. especially: screen -x can give what you want. and you can run any console
                                              Message 22 of 25 , Jun 2, 2009
                                              • 0 Attachment
                                                Wu, Yue 写道:
                                                > Hi, man, really thank you for so patient help and advicing! I'd better find a
                                                > right tool for my purpose, it's wrong to make vim to be an OS :)
                                                >

                                                I know what you want is a shared blackboard. For this use I recommend
                                                GNU Screen.

                                                especially: screen -x can give what you want. and you can run any
                                                console apps in screen, including vim.


                                                --~--~---------~--~----~------------~-------~--~----~
                                                You received this message from the "vim_use" maillist.
                                                For more information, visit http://www.vim.org/maillist.php
                                                -~----------~----~----~----~------~----~------~--~---
                                              • William
                                                Hi, Anyone tell me why the following commands in _vimrc DON T work? And, How can i map & so as to go to next/previous tab in the premise of NOT
                                                Message 23 of 25 , Jun 2, 2009
                                                • 0 Attachment
                                                  Hi,

                                                  Anyone tell me why the following commands in _vimrc DON'T work? And, How
                                                  can i map <C-=> & <C--> so as to go to next/previous tab in the premise
                                                  of NOT quitting INSERT model

                                                  map! <C-=> <C-o>gt
                                                  map! <C--> <C-o>gT


                                                  thanks

                                                  --
                                                  William <witicir@...>




                                                  --~--~---------~--~----~------------~-------~--~----~
                                                  You received this message from the "vim_use" maillist.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                  -~----------~----~----~----~------~----~------~--~---
                                                • John Little
                                                  ... One usually can t map control-minus or control-=, historically there was no such control code. To see what you can map, in insert mode type a control-V (or
                                                  Message 24 of 25 , Jun 2, 2009
                                                  • 0 Attachment
                                                    > Anyone tell me why the following commands...
                                                    > map! <C-=> <C-o>gt
                                                    > map! <C--> <C-o>gT

                                                    One usually can't map control-minus or control-=, historically there
                                                    was no such control code.
                                                    To see what you can map, in insert mode type a control-V (or control-Q
                                                    if control-V is paste for you) then a key combination you are
                                                    considering mapping. Watch out, though, weird stuff can happen if your
                                                    OS (or window manager, or session manager...) does something with the
                                                    key strokes.

                                                    > can i map <C-=> & <C--> so as to go to next/previous tab  in the premise

                                                    Your mappings are otherwise ok. In my gvim

                                                    map! <A-=> <C-o>gt
                                                    map! <A--> <C-o>gT

                                                    work with the Alt key. (In my vim in a terminal, these don't work,
                                                    alt-something gets turned into esc-something.)

                                                    HTH, John
                                                    --~--~---------~--~----~------------~-------~--~----~
                                                    You received this message from the "vim_use" maillist.
                                                    For more information, visit http://www.vim.org/maillist.php
                                                    -~----------~----~----~----~------~----~------~--~---
                                                  • Tony Mechelynck
                                                    ... The only _printable_ keys which have a portable Ctrl-equivalent are those foreseen in ASCII. These are: - characters 0x40 to 0x5F, whose Ctrl-equivalent is
                                                    Message 25 of 25 , Jun 3, 2009
                                                    • 0 Attachment
                                                      On 03/06/09 01:27, John Little wrote:
                                                      >
                                                      >
                                                      >> Anyone tell me why the following commands...
                                                      >> map!<C-=> <C-o>gt
                                                      >> map!<C--> <C-o>gT
                                                      >
                                                      > One usually can't map control-minus or control-=, historically there
                                                      > was no such control code.
                                                      > To see what you can map, in insert mode type a control-V (or control-Q
                                                      > if control-V is paste for you) then a key combination you are
                                                      > considering mapping. Watch out, though, weird stuff can happen if your
                                                      > OS (or window manager, or session manager...) does something with the
                                                      > key strokes.
                                                      >
                                                      >> can i map<C-=> & <C--> so as to go to next/previous tab in the premise
                                                      >
                                                      > Your mappings are otherwise ok. In my gvim
                                                      >
                                                      > map!<A-=> <C-o>gt
                                                      > map!<A--> <C-o>gT
                                                      >
                                                      > work with the Alt key. (In my vim in a terminal, these don't work,
                                                      > alt-something gets turned into esc-something.)
                                                      >
                                                      > HTH, John

                                                      The only _printable_ keys which have a portable Ctrl-equivalent are
                                                      those foreseen in ASCII. These are:

                                                      - characters 0x40 to 0x5F, whose Ctrl-equivalent is obtained by
                                                      subtracting 0x40;
                                                      - lowercase letters a to z, whose Ctrl-equivalent is the same as that of
                                                      the corresponding uppercase letter (meaning also that Ctrl-Shift-letter
                                                      is guaranteed to be the same as Ctrl-letter without Shift -- at least
                                                      according to the ASCII standard, which Vim follows here);
                                                      - the question mark 0x3F, where Ctrl-? is the DEL character, 0x7F.

                                                      Since the minus/dash (0x2D) and the equal sign (0x3D) are not among the
                                                      above, any program which recognizes Ctrl-- and/or Ctrl-= must use fancy
                                                      footwork for the purpose, and Vim doesn't.

                                                      Some _unprintable_ keys, such as F1 to F12 and the cursor-movement keys,
                                                      may have recognisable Ctrl-equivalents, but they are transmitted from
                                                      the keyboard to the program in a totally different way, which may be
                                                      OS-dependent and/or terminal-dependent. (FYI, I have found Shift-Fn to
                                                      be more portable in gvim over several OSes than are Ctrl-Fn or Alt-Fn.
                                                      Ctrl-arrow keys seem to work.)

                                                      As for the Alt key, gvim usually maps it to "OR with 0x80", which means
                                                      that an ASCII key with Alt will usually become synonymous with some
                                                      special or accented character. Caveat emptor! (especially in Insert
                                                      mode). For instance, ç (as in "garçon") is synonymous with Alt-g and é
                                                      (as in "risqué") with Alt-i. Both these French words are entries in my
                                                      Oxford's (unilingual) dictionary. How console terminals map
                                                      Alt-combinations depends on the terminal, and some may not map them at all.


                                                      Best regards,
                                                      Tony.
                                                      --
                                                      Corrupt, stupid grasping functionaries will make at least as big a
                                                      muddle of socialism as stupid, selfish and acquisitive employers can
                                                      make of capitalism.
                                                      -- Walter Lippmann

                                                      --~--~---------~--~----~------------~-------~--~----~
                                                      You received this message from the "vim_use" maillist.
                                                      For more information, visit http://www.vim.org/maillist.php
                                                      -~----------~----~----~----~------~----~------~--~---
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.