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

Re: How to co-editing?

Expand Messages
  • 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 1 of 25 , May 31, 2009
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.