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 :) ... 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.