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

Re: [patch] Process Interaction support for Vim (unstable version)

Expand Messages
  • Bram Moolenaar
    ... How about some documentation? So that we know how it s supposed to work. -- hundred-and-one symptoms of being an internet addict: 134. You consider
    Message 1 of 19 , Feb 26, 2009
    • 0 Attachment
      StarWing wrote:

      > this file is the patch to add feature Process Interaction to Vim.
      > base on Vim-7.2.108.
      >
      > THIS FILE IS UNSTABLE!! AND ONLY ON WINDOWS NOW!!
      >
      > made by StarWing <weasley_wx AT qq DOT com>
      >
      >
      > changed:
      > eval.txt (for functions added)
      > feature.h (add a new feature)
      > if_proc.c (main file, implement Process Interaction on Windows)
      > main.c (some clear work)
      > makefile (mvc and ming)
      > options.c & options.h (a new option)
      > proto.h (add if_proc.pro file included)
      >
      > other file is just patch ( some have GCC warnings, use minGW 3.4.5 -
      > Wall )

      How about some documentation? So that we know how it's supposed to
      work.

      --
      hundred-and-one symptoms of being an internet addict:
      134. You consider bandwidth to be more important than carats.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • StarWing
      ... documentation is on the way... i find it s hard to write, because some features are not stable, next version of the patch file will includes the documents.
      Message 2 of 19 , Feb 27, 2009
      • 0 Attachment
        > How about some documentation?  So that we know how it's supposed to
        > work.
        >
        > --
        > hundred-and-one symptoms of being an internet addict:
        > 134. You consider bandwidth to be more important than carats.

        documentation is on the way... i find it's hard to write, because some
        features are not stable, next version of the patch file will includes
        the documents.

        one word, it's a interface for process interaction with writting some
        simple Vim scriopt. it will be more flexible than implement vimshell &
        vimgdb with patch file.
        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Charles Campbell
        ... Hello, StarWing: I d like it if cross-platform dlopen/LoadLibrary was working better. I use vim s libcall which maps to (linux: libcall) (windows:
        Message 3 of 19 , Feb 27, 2009
        • 0 Attachment
          StarWing wrote:
          >> How about some documentation? So that we know how it's supposed to
          >> work.
          >>
          >> --
          >> hundred-and-one symptoms of being an internet addict:
          >> 134. You consider bandwidth to be more important than carats.
          >>
          >
          > documentation is on the way... i find it's hard to write, because some
          > features are not stable, next version of the patch file will includes
          > the documents.
          >
          > one word, it's a interface for process interaction with writting some
          > simple Vim scriopt. it will be more flexible than implement vimshell &
          > vimgdb with patch file.
          >
          Hello, StarWing:

          I'd like it if cross-platform dlopen/LoadLibrary was working better. I use
          vim's libcall which maps to (linux: libcall) (windows: LoadLibrary)
          but every time libcall() is used the library gets re-opened. Never seems
          to be closed, either. One effect: one can't have static variables in
          the external
          library (which is what precludes many system calls).

          My gdbmgr (http://mysite.verizon.net/astronaut/vim/index.html#GDBMGR)
          uses libcall()
          anyway; I work around the static variable limitation by using shared memory.

          If you're interested, you can see some snapshots:
          http://mysite.verizon.net/astronaut/pix/gdbmgr1.jpg
          http://mysite.verizon.net/astronaut/pix/gdbmgr2.jpg

          Regards,
          Chip Campbell


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tony Mechelynck
          ... Yes: the announced eval.txt diff was not included. That s actually a good point, because as long as your patch doesn t make it into official Vim , you
          Message 4 of 19 , Feb 27, 2009
          • 0 Attachment
            On 27/02/09 04:04, Bram Moolenaar wrote:
            >
            > StarWing wrote:
            >
            >> this file is the patch to add feature Process Interaction to Vim.
            >> base on Vim-7.2.108.
            >>
            >> THIS FILE IS UNSTABLE!! AND ONLY ON WINDOWS NOW!!
            >>
            >> made by StarWing<weasley_wx AT qq DOT com>
            >>
            >>
            >> changed:
            >> eval.txt (for functions added)
            >> feature.h (add a new feature)
            >> if_proc.c (main file, implement Process Interaction on Windows)
            >> main.c (some clear work)
            >> makefile (mvc and ming)
            >> options.c& options.h (a new option)
            >> proto.h (add if_proc.pro file included)
            >>
            >> other file is just patch ( some have GCC warnings, use minGW 3.4.5 -
            >> Wall )
            >
            > How about some documentation? So that we know how it's supposed to
            > work.
            >

            Yes: the announced eval.txt diff was not included. That's actually a
            good point, because as long as your patch doesn't make it into "official
            Vim", you shouldn't touch the official Vim documentation. Why? Because
            whenever runtime files are updated, the update will sync the user's
            $VIMRUNTIME/doc/ with the _official_
            ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
            nonstandard changes you made. Publish your documentation as a separate
            help file, which can be dropped (on any platform) into
            $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
            into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
            touch it. After downloading the helpfile to the appropriate doc/
            subdirectory, run ":helptags" (q.v.) on that directory to integrate its
            new contents into the built-in help. The "LOCAL ADDITIONS" paragraph at
            ":help local-additions" will be automagically updated (in Vim only, not
            on the disk). This means that the first line of your new helpfile should
            start with its name (between stars) followed on the same line by a short
            summary of what the helpfile talks about.


            Best regards,
            Tony.
            --
            "I can remember when a good politician had to be 75 percent ability and
            25 percent actor, but I can well see the day when the reverse could be
            true."
            -- Harry Truman

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Markus Heidelberg
            ... This workaround with a separate file is not needed if you use the vim_extended git repository. Markus --~--~---------~--~----~------------~-------~--~----~
            Message 5 of 19 , Feb 27, 2009
            • 0 Attachment
              Tony Mechelynck, 27.02.2009:
              >
              > On 27/02/09 04:04, Bram Moolenaar wrote:
              > >
              > > How about some documentation? So that we know how it's supposed to
              > > work.
              >
              > Yes: the announced eval.txt diff was not included. That's actually a
              > good point, because as long as your patch doesn't make it into "official
              > Vim", you shouldn't touch the official Vim documentation. Why? Because
              > whenever runtime files are updated, the update will sync the user's
              > $VIMRUNTIME/doc/ with the _official_
              > ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
              > nonstandard changes you made. Publish your documentation as a separate
              > help file, which can be dropped (on any platform) into
              > $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
              > into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
              > touch it.

              This workaround with a separate file is not needed if you use the
              vim_extended git repository.

              Markus


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Tony Mechelynck
              ... You cannot expect that all _users_ of your patches will use it. I don t, for one, and I bet I m not alone of my case. So, if you want to distribute your
              Message 6 of 19 , Feb 27, 2009
              • 0 Attachment
                On 28/02/09 03:44, Markus Heidelberg wrote:
                > Tony Mechelynck, 27.02.2009:
                >> On 27/02/09 04:04, Bram Moolenaar wrote:
                >>> How about some documentation? So that we know how it's supposed to
                >>> work.
                >> Yes: the announced eval.txt diff was not included. That's actually a
                >> good point, because as long as your patch doesn't make it into "official
                >> Vim", you shouldn't touch the official Vim documentation. Why? Because
                >> whenever runtime files are updated, the update will sync the user's
                >> $VIMRUNTIME/doc/ with the _official_
                >> ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
                >> nonstandard changes you made. Publish your documentation as a separate
                >> help file, which can be dropped (on any platform) into
                >> $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
                >> into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
                >> touch it.
                >
                > This workaround with a separate file is not needed if you use the
                > vim_extended git repository.
                >
                > Markus

                You cannot expect that all _users_ of your patches will use it. I don't,
                for one, and I bet I'm not alone of my case. So, if you want to
                distribute your plugin to _any_ Vim users, you cannot afford to make any
                changes in the official runtimes (including the official help) for the
                reasons I mentioned: any user doing a runtime upgrade (by one of the
                conventional methods such as e.g. rsync with ftp.nluug.nl::Vim/runtime/
                or ftp from ftp://ftp.vim.org/pub/vim/runtime/), will immediately lose
                all your changes to $VIMRUNTIME/**/*.


                Best regards,
                Tony.
                --
                God is not dead! He's alive and autographing bibles at Cody's

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Markus Heidelberg
                ... I don t. I just pointed out an advantage. BTW: these are not _my_ patches. ... That s not true. Users have always the chance to reapply the patches they
                Message 7 of 19 , Feb 27, 2009
                • 0 Attachment
                  Tony Mechelynck, 28.02.2009:
                  >
                  > On 28/02/09 03:44, Markus Heidelberg wrote:
                  > > Tony Mechelynck, 27.02.2009:
                  > >> On 27/02/09 04:04, Bram Moolenaar wrote:
                  > >>> How about some documentation? So that we know how it's supposed to
                  > >>> work.
                  > >> Yes: the announced eval.txt diff was not included. That's actually a
                  > >> good point, because as long as your patch doesn't make it into "official
                  > >> Vim", you shouldn't touch the official Vim documentation. Why? Because
                  > >> whenever runtime files are updated, the update will sync the user's
                  > >> $VIMRUNTIME/doc/ with the _official_
                  > >> ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
                  > >> nonstandard changes you made. Publish your documentation as a separate
                  > >> help file, which can be dropped (on any platform) into
                  > >> $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
                  > >> into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
                  > >> touch it.
                  > >
                  > > This workaround with a separate file is not needed if you use the
                  > > vim_extended git repository.
                  > >
                  > > Markus
                  >
                  > You cannot expect that all _users_ of your patches will use it.

                  I don't. I just pointed out an advantage.
                  BTW: these are not _my_ patches.

                  > So, if you want to
                  > distribute your plugin to _any_ Vim users, you cannot afford to make any
                  > changes in the official runtimes (including the official help) for the
                  > reasons I mentioned:

                  That's not true. Users have always the chance to reapply the patches
                  they are using.

                  And: patches can also contain runtime changes outside of runtime/doc/,
                  where using a separate file doesn't work any more. Or even inside
                  runtime/doc/, where existing documentation has to be adjusted. For the
                  'relativenumber' patch for example, there are 8 files:

                  http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=aef4930ebeece6fa9c6383b532dabdd56f105cd5

                  So using a separate file for the documentation is not a generic solution
                  at all.

                  > any user doing a runtime upgrade (by one of the
                  > conventional methods such as e.g. rsync with ftp.nluug.nl::Vim/runtime/
                  > or ftp from ftp://ftp.vim.org/pub/vim/runtime/), will immediately lose
                  > all your changes to $VIMRUNTIME/**/*.

                  So patch authors should use this "separate file" workaround (which
                  doesn't actually really work), because Vim is not managed in a central
                  way and people don't use the right tool for the right job?

                  With this downside of the runtime files overwriting custom changes, I
                  can't understand why you are so proposing your "only-use-the-patch-tool"
                  workflow. And the git repository simply solves this runtime problem.

                  Markus


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Tony Mechelynck
                  ... - Not everyone has git installed or is willing to install it and learn how to use it, when the time-tested procedure of downloading patches one by one or
                  Message 8 of 19 , Feb 27, 2009
                  • 0 Attachment
                    On 28/02/09 04:54, Markus Heidelberg wrote:
                    > Tony Mechelynck, 28.02.2009:
                    >> On 28/02/09 03:44, Markus Heidelberg wrote:
                    >>> Tony Mechelynck, 27.02.2009:
                    >>>> On 27/02/09 04:04, Bram Moolenaar wrote:
                    >>>>> How about some documentation? So that we know how it's supposed to
                    >>>>> work.
                    >>>> Yes: the announced eval.txt diff was not included. That's actually a
                    >>>> good point, because as long as your patch doesn't make it into "official
                    >>>> Vim", you shouldn't touch the official Vim documentation. Why? Because
                    >>>> whenever runtime files are updated, the update will sync the user's
                    >>>> $VIMRUNTIME/doc/ with the _official_
                    >>>> ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
                    >>>> nonstandard changes you made. Publish your documentation as a separate
                    >>>> help file, which can be dropped (on any platform) into
                    >>>> $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
                    >>>> into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
                    >>>> touch it.
                    >>> This workaround with a separate file is not needed if you use the
                    >>> vim_extended git repository.
                    >>>
                    >>> Markus
                    >> You cannot expect that all _users_ of your patches will use it.
                    >
                    > I don't. I just pointed out an advantage.
                    > BTW: these are not _my_ patches.
                    >
                    >> So, if you want to
                    >> distribute your plugin to _any_ Vim users, you cannot afford to make any
                    >> changes in the official runtimes (including the official help) for the
                    >> reasons I mentioned:
                    >
                    > That's not true. Users have always the chance to reapply the patches
                    > they are using.
                    >
                    > And: patches can also contain runtime changes outside of runtime/doc/,
                    > where using a separate file doesn't work any more. Or even inside
                    > runtime/doc/, where existing documentation has to be adjusted. For the
                    > 'relativenumber' patch for example, there are 8 files:
                    >
                    > http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=aef4930ebeece6fa9c6383b532dabdd56f105cd5
                    >
                    > So using a separate file for the documentation is not a generic solution
                    > at all.
                    >
                    >> any user doing a runtime upgrade (by one of the
                    >> conventional methods such as e.g. rsync with ftp.nluug.nl::Vim/runtime/
                    >> or ftp from ftp://ftp.vim.org/pub/vim/runtime/), will immediately lose
                    >> all your changes to $VIMRUNTIME/**/*.
                    >
                    > So patch authors should use this "separate file" workaround (which
                    > doesn't actually really work), because Vim is not managed in a central
                    > way and people don't use the right tool for the right job?
                    >
                    > With this downside of the runtime files overwriting custom changes, I
                    > can't understand why you are so proposing your "only-use-the-patch-tool"
                    > workflow. And the git repository simply solves this runtime problem.
                    >
                    > Markus

                    - Not everyone has git installed or is willing to install it and learn
                    how to use it, when the time-tested procedure of downloading patches one
                    by one or 100 at a time over ftp, applying them using patch, and
                    updating the runtime files using rsync, works perfectly.
                    - Unlike the runtime files (inside or outside runtime/doc/ but inside
                    runtime/ and its subfolders), changes to src/* or to anything outside
                    runtime/ are not affected by runtime updates
                    - The "separate file" method works perfectly. Just drop the concerned
                    helpfile in the doc/ subdirectory of one of the 'runtimepath' folders
                    other than $VIMRUNTIME (and create the needed directory if it doesn't
                    yet exist), run ":helptags" on the directory where you just dropped the
                    file, and voilà! Runtime upgrades will leave that alone, the only time
                    you will have to go back to it will be if and when there is an update to
                    that particular file. Bill McCarthy uses that "separate file" method for
                    the help for his additional float functions, Dr. Chip Campbell uses it
                    for those of his plugins which are not part of the standard Vim
                    distribution, Benji Fisher uses it for his matchit plugin, I'm using
                    Bill's patch, matchit, and several of Dr. Chip's plugins, and it works
                    perfectly.


                    Regards,
                    Tony.
                    --
                    It's the opinion of some that crops could be grown on the moon. Which
                    raises the fear that it may not be long before we're paying somebody
                    not to.
                    -- Franklin P. Jones

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Markus Heidelberg
                    ... Obviously it doesn t work perfectly for updating the runtime files. Otherwise we wouldn t have this discussion. ... Correct, but what do you want to say
                    Message 9 of 19 , Feb 28, 2009
                    • 0 Attachment
                      Tony Mechelynck, 28.02.2009:
                      >
                      > On 28/02/09 04:54, Markus Heidelberg wrote:
                      > > Tony Mechelynck, 28.02.2009:
                      > >> On 28/02/09 03:44, Markus Heidelberg wrote:
                      > >>> Tony Mechelynck, 27.02.2009:
                      > >>>> On 27/02/09 04:04, Bram Moolenaar wrote:
                      > >>>>> How about some documentation? So that we know how it's supposed to
                      > >>>>> work.
                      > >>>> Yes: the announced eval.txt diff was not included. That's actually a
                      > >>>> good point, because as long as your patch doesn't make it into "official
                      > >>>> Vim", you shouldn't touch the official Vim documentation. Why? Because
                      > >>>> whenever runtime files are updated, the update will sync the user's
                      > >>>> $VIMRUNTIME/doc/ with the _official_
                      > >>>> ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any
                      > >>>> nonstandard changes you made. Publish your documentation as a separate
                      > >>>> help file, which can be dropped (on any platform) into
                      > >>>> $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix)
                      > >>>> into ~/.vim/doc/, where (in all three cases), runtime upgrade won't
                      > >>>> touch it.
                      > >>> This workaround with a separate file is not needed if you use the
                      > >>> vim_extended git repository.
                      > >>>
                      > >>> Markus
                      > >> You cannot expect that all _users_ of your patches will use it.
                      > >
                      > > I don't. I just pointed out an advantage.
                      > > BTW: these are not _my_ patches.
                      > >
                      > >> So, if you want to
                      > >> distribute your plugin to _any_ Vim users, you cannot afford to make any
                      > >> changes in the official runtimes (including the official help) for the
                      > >> reasons I mentioned:
                      > >
                      > > That's not true. Users have always the chance to reapply the patches
                      > > they are using.
                      > >
                      > > And: patches can also contain runtime changes outside of runtime/doc/,
                      > > where using a separate file doesn't work any more. Or even inside
                      > > runtime/doc/, where existing documentation has to be adjusted. For the
                      > > 'relativenumber' patch for example, there are 8 files:
                      > >
                      > > http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=aef4930ebeece6fa9c6383b532dabdd56f105cd5
                      > >
                      > > So using a separate file for the documentation is not a generic solution
                      > > at all.
                      > >
                      > >> any user doing a runtime upgrade (by one of the
                      > >> conventional methods such as e.g. rsync with ftp.nluug.nl::Vim/runtime/
                      > >> or ftp from ftp://ftp.vim.org/pub/vim/runtime/), will immediately lose
                      > >> all your changes to $VIMRUNTIME/**/*.
                      > >
                      > > So patch authors should use this "separate file" workaround (which
                      > > doesn't actually really work), because Vim is not managed in a central
                      > > way and people don't use the right tool for the right job?
                      > >
                      > > With this downside of the runtime files overwriting custom changes, I
                      > > can't understand why you are so proposing your "only-use-the-patch-tool"
                      > > workflow. And the git repository simply solves this runtime problem.
                      > >
                      > > Markus
                      >
                      > - Not everyone has git installed or is willing to install it and learn
                      > how to use it, when the time-tested procedure of downloading patches one
                      > by one or 100 at a time over ftp, applying them using patch, and
                      > updating the runtime files using rsync, works perfectly.

                      Obviously it doesn't work perfectly for updating the runtime files.
                      Otherwise we wouldn't have this discussion.

                      > - Unlike the runtime files (inside or outside runtime/doc/ but inside
                      > runtime/ and its subfolders), changes to src/* or to anything outside
                      > runtime/ are not affected by runtime updates

                      Correct, but what do you want to say with it?

                      > - The "separate file" method works perfectly. Just drop the concerned
                      > helpfile in the doc/ subdirectory of one of the 'runtimepath' folders
                      > other than $VIMRUNTIME (and create the needed directory if it doesn't
                      > yet exist), run ":helptags" on the directory where you just dropped the
                      > file, and voilà! Runtime upgrades will leave that alone,

                      Haven't you read my mail? It doesn't work for runtime changes, which you
                      HAVE to put into existing files. Please response to this instead of
                      repeating yourself.

                      > the only time
                      > you will have to go back to it will be if and when there is an update to
                      > that particular file. Bill McCarthy uses that "separate file" method for
                      > the help for his additional float functions,

                      > Dr. Chip Campbell uses it
                      > for those of his plugins which are not part of the standard Vim
                      > distribution, Benji Fisher uses it for his matchit plugin,

                      Plugins are an entirely different case. They don't have anything to do
                      with the source tree. That's the purpose of plugins, to not be dependent
                      on the code. Plugins work for several Vim versions, patches not
                      necessarily.

                      We are talking about patches against the source tree. You have to
                      compile again after applying a patch. And the runtime files belong to
                      Vim's source tree as well as the source files.

                      > I'm using
                      > Bill's patch, matchit, and several of Dr. Chip's plugins, and it works
                      > perfectly.

                      Your workflow works for Bill's patch. But it surely isn't perfect to
                      have a separate file instead of having his function descriptions
                      integrated in eval.txt, where they belong, between the other functions.

                      After putting the content of float-ext.txt into eval.txt

                      http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=b1c65e933dab3fb14042c56af362c168dce91532

                      I sorted the descriptions

                      http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=d9664e694ddeb8cc0218f6869dc92c27ad1fd2ab

                      and now it's well integrated.

                      I could also add the one-line descriptions in the TOC (:help functions)
                      and to the grouped one-line descriptions (:help function-list).
                      You don't have this possibility.

                      Markus


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Tony Mechelynck
                      On 28/02/09 11:34, Markus Heidelberg wrote: [...] This debate is going nowhere. You won t change your mind, and neither shall I, so I m shutting up. Best
                      Message 10 of 19 , Feb 28, 2009
                      • 0 Attachment
                        On 28/02/09 11:34, Markus Heidelberg wrote:
                        [...]

                        This debate is going nowhere. You won't change your mind, and neither
                        shall I, so I'm shutting up.


                        Best regards,
                        Tony.
                        --
                        It's odd, and a little unsettling, to reflect upon the fact that
                        English is the only major language in which "I" is capitalized; in many
                        other languages "You" is capitalized and the "i" is lower case.
                        -- Sydney J. Harris

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Markus Heidelberg
                        ... OK, do so, without having responded to the main argument a single time, although I ve reminded you. It seems you are running out of arguments. Please put
                        Message 11 of 19 , Feb 28, 2009
                        • 0 Attachment
                          Tony Mechelynck, 28.02.2009:
                          >
                          > On 28/02/09 11:34, Markus Heidelberg wrote:
                          > [...]
                          >
                          > This debate is going nowhere. You won't change your mind, and neither
                          > shall I, so I'm shutting up.

                          OK, do so, without having responded to the main argument a single time,
                          although I've reminded you. It seems you are running out of arguments.
                          Please put down your anti-git attitude and accept its usefulness,
                          at least in the case of the runtime updates.

                          Markus


                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Tony Mechelynck
                          ... What main argument? That I should believe in git the way others believe in God? Well, I don t. What I have satisfies me -- and in the case of patches to
                          Message 12 of 19 , Feb 28, 2009
                          • 0 Attachment
                            On 28/02/09 12:06, Markus Heidelberg wrote:
                            > Tony Mechelynck, 28.02.2009:
                            >> On 28/02/09 11:34, Markus Heidelberg wrote:
                            >> [...]
                            >>
                            >> This debate is going nowhere. You won't change your mind, and neither
                            >> shall I, so I'm shutting up.
                            >
                            > OK, do so, without having responded to the main argument a single time,
                            > although I've reminded you. It seems you are running out of arguments.
                            > Please put down your anti-git attitude and accept its usefulness,
                            > at least in the case of the runtime updates.
                            >
                            > Markus

                            What main argument? That I should believe in git the way others believe
                            in God? Well, I don't. What I have satisfies me -- and in the case of
                            patches to the official runtime files, sooner or later (sometimes even
                            before the patch is published) the official runtime repositories will
                            acquire them, so that isn't a problem. _Un_official patches to runtime
                            files, OTOH, should never be done under $VIMRUNTIME but brought out of
                            it: in the case of *.vim files they should be moved, in modified form,
                            to some tree early in 'runtimepath' so they will override the official
                            file of the same name, and in the case of helpfiles, new helpfiles
                            should be written, with new filenames, containing only the differences,
                            and they should be put, not into $VIMRUNTIME/doc but into the doc/
                            subdir of some other 'runtimepath' tree. This procedure is compatible
                            with all possible ways of updating runtime files, while yours requires
                            converting to git. Well, I believe in plurality of upgrade methods the
                            way I believe in plurality of Windows compilers, in plurality of methods
                            to achieve a given goal within Vim, or, outside of Vim, in plurality of
                            human languages or in plurality of religious creeds. In the case of
                            religion, I regard myself as a deist after having long been an agnostic,
                            but I believe in liberty of religion: practice your own religion the way
                            you want to, let me practice mine the way I do, and if the next guy
                            wants to practice no religion at all, let's let him do so. Someday I'll
                            tell you Aesop's fable "The Blind Men and the Elephant" and how I apply
                            it to theologians (including amateur ones, i.e., everyday people) and God.


                            Best regards,
                            Tony.
                            --
                            You need only reflect that one of the best ways to get yourself a
                            reputation as a dangerous citizen these days is to go about repeating
                            the very phrases which our founding fathers used in the struggle for
                            independence.
                            -- Charles A. Beard

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Markus Heidelberg
                            ... I didn t want to repeat it for the third time, but since you don t understand, here it is, copied from a former mail: It doesn t work for runtime changes,
                            Message 13 of 19 , Feb 28, 2009
                            • 0 Attachment
                              Tony Mechelynck, 28.02.2009:
                              >
                              > On 28/02/09 12:06, Markus Heidelberg wrote:
                              > > Tony Mechelynck, 28.02.2009:
                              > >> On 28/02/09 11:34, Markus Heidelberg wrote:
                              > >> [...]
                              > >>
                              > >> This debate is going nowhere. You won't change your mind, and neither
                              > >> shall I, so I'm shutting up.
                              > >
                              > > OK, do so, without having responded to the main argument a single time,
                              > > although I've reminded you. It seems you are running out of arguments.
                              > > Please put down your anti-git attitude and accept its usefulness,
                              > > at least in the case of the runtime updates.
                              > >
                              > > Markus
                              >
                              > What main argument?

                              I didn't want to repeat it for the third time, but since you don't
                              understand, here it is, copied from a former mail:

                              It doesn't work for runtime changes, which you HAVE to put into existing
                              files.

                              > That I should believe in git the way others believe
                              > in God?

                              Don't imply something to me, which I have never expressed.

                              > Well, I don't. What I have satisfies me -- and in the case of
                              > patches to the official runtime files, sooner or later (sometimes even
                              > before the patch is published) the official runtime repositories will
                              > acquire them, so that isn't a problem.

                              Yes, official patches are not a problem.

                              > _Un_official patches to runtime
                              > files, OTOH, should never be done under $VIMRUNTIME but brought out of
                              > it: in the case of *.vim files they should be moved, in modified form,
                              > to some tree early in 'runtimepath' so they will override the official
                              > file of the same name, and in the case of helpfiles, new helpfiles
                              > should be written, with new filenames, containing only the differences,
                              > and they should be put, not into $VIMRUNTIME/doc but into the doc/
                              > subdir of some other 'runtimepath' tree.

                              Fine, here finally is your response to the argument I was referring to
                              as the "main argument".
                              And you proposed solution is crap. Everytime the official runtime files
                              are updated, the patch has to be updated for his copied and modified
                              files as well, else it will go the other way round: the patch will
                              revert the official runtime updates (of course not in the source tree,
                              but in the result when using Vim), previously the official runtime
                              updates have reverted the runtime files from the patch.

                              > This procedure is compatible
                              > with all possible ways of updating runtime files, while yours requires
                              > converting to git.

                              That's wrong, my procedure is also doable for non-git users:

                              patch -R < your-custom.patch
                              update runtime files via rsync or ftp
                              patch < your-custom.patch

                              > Well, I believe in plurality of upgrade methods the
                              > way I believe in plurality of Windows compilers, in plurality of methods
                              > to achieve a given goal within Vim, or, outside of Vim, in plurality of
                              > human languages or in plurality of religious creeds. In the case of
                              > religion, I regard myself as a deist after having long been an agnostic,
                              > but I believe in liberty of religion: practice your own religion the way
                              > you want to, let me practice mine the way I do, and if the next guy
                              > wants to practice no religion at all, let's let him do so. Someday I'll
                              > tell you Aesop's fable "The Blind Men and the Elephant" and how I apply
                              > it to theologians (including amateur ones, i.e., everyday people) and God.

                              I thought you wanted to shut up!? Instead of this you are writing a
                              novel, talking about religion and Windows compilers.

                              Markus


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Milan Vancura
                              ... I think everything is clear: StarWing has a problem and Markus suggested a solution. The suggested solution not only works for StarWing but doesn t harm
                              Message 14 of 19 , Mar 2, 2009
                              • 0 Attachment
                                >
                                > Tony Mechelynck, 28.02.2009:
                                > >
                                > > On 28/02/09 12:06, Markus Heidelberg wrote:
                                > > > Tony Mechelynck, 28.02.2009:
                                > > >> On 28/02/09 11:34, Markus Heidelberg wrote:
                                > > >> [...]
                                > > >>
                                > > >> This debate is going nowhere. You won't change your mind, and neither
                                > > >> shall I, so I'm shutting up.
                                > > >
                                > > > OK, do so, without having responded to the main argument a single time,
                                > > > although I've reminded you. It seems you are running out of arguments.
                                > > > Please put down your anti-git attitude and accept its usefulness,
                                > > > at least in the case of the runtime updates.
                                > > >
                                > > > Markus
                                > >
                                > > What main argument?
                                >
                                > I didn't want to repeat it for the third time, but since you don't
                                > understand, here it is, copied from a former mail:
                                >
                                > It doesn't work for runtime changes, which you HAVE to put into existing
                                > files.

                                I think everything is clear: StarWing has a problem and Markus suggested a
                                solution. The suggested solution not only works for StarWing but doesn't harm
                                anyone in his/her workflow. It allows the others to get a better patch from
                                StarWing on the vim_dev list (as the patch will be tested better) so it will be
                                a clear benefit for everyone.

                                Users of vim_extended repository have a little advantage more: they can work
                                with the patch(set) more interactively, merge it with their patches, select
                                patches/branches to merge and test conflicts or a cooperation of several
                                features at once etc. All this can be done localy and, after the first tree
                                clone, offline. More about git advantages (and not only git, Mercurial is an
                                example of other VCS offering a similar level of usability; and there may be
                                others) was already said on this list some time ago. Just check the archive.
                                There you will see, Tony, that this is not any exception: James Vega maintains
                                a repository for Debian purposes, MacVim is maintained in a similar way as
                                well... There must be something good behind it :-)

                                But even people using ftp+rsync method can achieve the same just using
                                different method (in a more complicated way, my opinion, but this is a
                                different story and not my decision) as everyone still gets a patch through the
                                vim_dev mailing list.

                                This all is possible not only because of git but because of Markus's great work
                                on vim_extended repository which combines vim and runtime files together and
                                allows feature branches for testing.

                                Similarly, if I need to check something in the vim history, another repository,
                                made by Christian Michon, is very helpful (http://github.com/cmichon/vim). I
                                know how hard was to work without its help, when, one time, I needed look to
                                vim 5.4 which is not included in Christian's repo and I did have to find
                                patches myself...

                                So I want to thank Markus and Christian for their work here. Thank you, guys,
                                as you made my life easier!

                                Milan
                                --
                                Milan Vancura, Prague, Czech Republic, Europe

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_dev" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Markus Heidelberg
                                ... Indeed! I used it, when I recently used git-bisect, since vim_extended doesn t have much useful history for Vim 7.1 ... No problem, this is what we are
                                Message 15 of 19 , Mar 2, 2009
                                • 0 Attachment
                                  Milan Vancura, 02.03.2009:
                                  > Similarly, if I need to check something in the vim history, another repository,
                                  > made by Christian Michon, is very helpful (http://github.com/cmichon/vim).

                                  Indeed! I used it, when I recently used git-bisect, since vim_extended
                                  doesn't have much useful history for Vim 7.1

                                  > So I want to thank Markus and Christian for their work here. Thank you, guys,
                                  > as you made my life easier!

                                  No problem, this is what we are born for :)

                                  Markus


                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_dev" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Tony Mechelynck
                                  ... Any such unofficial patch to runtime files will have to be reapplied after each and every rsync run. Possible, but not practical, and it could readily be
                                  Message 16 of 19 , Mar 2, 2009
                                  • 0 Attachment
                                    On 02/03/09 13:48, Milan Vancura wrote:
                                    >> Tony Mechelynck, 28.02.2009:
                                    >>> On 28/02/09 12:06, Markus Heidelberg wrote:
                                    >>>> Tony Mechelynck, 28.02.2009:
                                    >>>>> On 28/02/09 11:34, Markus Heidelberg wrote:
                                    >>>>> [...]
                                    >>>>>
                                    >>>>> This debate is going nowhere. You won't change your mind, and neither
                                    >>>>> shall I, so I'm shutting up.
                                    >>>> OK, do so, without having responded to the main argument a single time,
                                    >>>> although I've reminded you. It seems you are running out of arguments.
                                    >>>> Please put down your anti-git attitude and accept its usefulness,
                                    >>>> at least in the case of the runtime updates.
                                    >>>>
                                    >>>> Markus
                                    >>> What main argument?
                                    >> I didn't want to repeat it for the third time, but since you don't
                                    >> understand, here it is, copied from a former mail:
                                    >>
                                    >> It doesn't work for runtime changes, which you HAVE to put into existing
                                    >> files.
                                    >
                                    > I think everything is clear: StarWing has a problem and Markus suggested a
                                    > solution. The suggested solution not only works for StarWing but doesn't harm
                                    > anyone in his/her workflow. It allows the others to get a better patch from
                                    > StarWing on the vim_dev list (as the patch will be tested better) so it will be
                                    > a clear benefit for everyone.
                                    >
                                    > Users of vim_extended repository have a little advantage more: they can work
                                    > with the patch(set) more interactively, merge it with their patches, select
                                    > patches/branches to merge and test conflicts or a cooperation of several
                                    > features at once etc. All this can be done localy and, after the first tree
                                    > clone, offline. More about git advantages (and not only git, Mercurial is an
                                    > example of other VCS offering a similar level of usability; and there may be
                                    > others) was already said on this list some time ago. Just check the archive.
                                    > There you will see, Tony, that this is not any exception: James Vega maintains
                                    > a repository for Debian purposes, MacVim is maintained in a similar way as
                                    > well... There must be something good behind it :-)
                                    >
                                    > But even people using ftp+rsync method can achieve the same just using
                                    > different method (in a more complicated way, my opinion, but this is a
                                    > different story and not my decision) as everyone still gets a patch through the
                                    > vim_dev mailing list.

                                    Any such unofficial patch to runtime files will have to be reapplied
                                    after each and every rsync run. Possible, but not practical, and it
                                    could readily be avoided by avoiding placing any unofficial runtime
                                    files or runtime file changes in the $VIMRUNTIME tree. Wasn't I clear?

                                    >
                                    > This all is possible not only because of git but because of Markus's great work
                                    > on vim_extended repository which combines vim and runtime files together and
                                    > allows feature branches for testing.
                                    >
                                    > Similarly, if I need to check something in the vim history, another repository,
                                    > made by Christian Michon, is very helpful (http://github.com/cmichon/vim). I
                                    > know how hard was to work without its help, when, one time, I needed look to
                                    > vim 5.4 which is not included in Christian's repo and I did have to find
                                    > patches myself...
                                    >
                                    > So I want to thank Markus and Christian for their work here. Thank you, guys,
                                    > as you made my life easier!
                                    >
                                    > Milan


                                    Regards,
                                    Tony.
                                    --
                                    We ARE as gods and might as well get good at it.
                                    -- Whole Earth Catalog

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_dev" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • Markus Heidelberg
                                    ... The words not practical and readily be avoided from someone, who uses an ftp client, patch and rsync just to update a single software package? You can
                                    Message 17 of 19 , Mar 3, 2009
                                    • 0 Attachment
                                      Tony Mechelynck, 03.03.2009:
                                      > On 02/03/09 13:48, Milan Vancura wrote:
                                      > > But even people using ftp+rsync method can achieve the same just using
                                      > > different method (in a more complicated way, my opinion, but this is a
                                      > > different story and not my decision) as everyone still gets a patch through the
                                      > > vim_dev mailing list.
                                      >
                                      > Any such unofficial patch to runtime files will have to be reapplied
                                      > after each and every rsync run. Possible, but not practical, and it
                                      > could readily be avoided by avoiding placing any unofficial runtime
                                      > files or runtime file changes in the $VIMRUNTIME tree.

                                      The words "not practical" and "readily be avoided" from someone, who
                                      uses an ftp client, patch and rsync just to update a single software
                                      package? You can also use telnet to fetch emails.

                                      Let's recapitulate the normal solution and your broken solution for a
                                      last time, without considering git, but only the conventional way with
                                      ftp, patch and rsync. I hate writing so long mails and meanwhile I doubt
                                      you understand it after reading, but I will try anyway.
                                      For unofficial patches, not for plugins:

                                      Normal solution:

                                      - patches contain changes to the runtime files directly in the patch
                                      - so you have 1 patch file and nothing else

                                      - apply the patch with the patch tool

                                      - rsync would overwrite the changes a patch introduces
                                      - so reverse the patch
                                      - then update the official runtime files with rsync
                                      - and finally reapply the patch

                                      - convenient? not really, but you chose so with the ftp/patch/rsync
                                      workflow
                                      - automatable? yes, can be achieved easily with a script


                                      Broken solution:

                                      - patches only contain changes to the source files directly in the
                                      patch. Changes to the runtime files are done in separate files,
                                      preferably as a new file (e.g. for new documentation). But if it is
                                      not possible to use a new file, but necessary to adjust existing
                                      files, you copy and modify it for your patch.
                                      - so you have 1 patch file for the sources, some new files and some
                                      modified files

                                      - apply the patch with the patch tool
                                      - copy the new files into the right subdirectory of ~/.vim/
                                      - copy the modified files into the right subdirectory of ~/.vim/
                                      Since the files in this directory are loaded before the ones in
                                      $VIMRUNTIME, Vim uses the modified files instead of the unmodified
                                      without the changes

                                      - rsync wouldn't overwrite the changes a patch introduces, but if files
                                      are updated, which the patch has copied and modified, Vim will still
                                      use them. They contain the changes of the patch, but not the new
                                      changes from rsync
                                      - so update the official runtime files with rsync
                                      - somehow integrate the updates in your copied and modified files
                                      - maybe by creating a temporary patch between the old runtime files
                                      before the rsync updates and your modified runtime files
                                      - then copy the files you modified and were updated by rsync to ~/.vim/
                                      - finally reapply your temporary patch to the new copied files in ~/.vim/

                                      - convenient? not at all, even the first integration requires several
                                      steps to use the unofficial patch and is more complicated, because you
                                      have to deal with more than just 1 single patch file
                                      - automatable? yes, but requires more steps


                                      Conslusion:

                                      With the ftp/patch/rsync workflow, you have to care about the runtime
                                      files after the first integration of an unofficial patch in either ways.
                                      You have to use reapply tricks with patch to not lose changes, either in
                                      the official runtime files or in the runtime files changed by a patch.

                                      > Wasn't I clear?

                                      Yes, you was clear that you didn't get it and refused to learn.

                                      Markus


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