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

Vim for Windows (Updated to 7.4.193)

Expand Messages
  • Alexander Shukaev
    Hey everyone, Vim for Windows [https://bitbucket.org/Haroogan/vim-for-windows] has been updated to 7.4.193. Starting from this release, the support for the
    Message 1 of 23 , Mar 11, 2014
      Hey everyone,

      Vim for Windows [https://bitbucket.org/Haroogan/vim-for-windows%5d has been updated to 7.4.193. Starting from this release, the support for the latest Lua (5.2) has been included.

      Best regards,
      Alexander Shukaev

      --
      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/d/optout.
    • Linda W
      ... Um... you seemed to have missed including perl all-together. You got Ruby, Lua but you have *two* versions of python. Shouldn t one of those been perl?
      Message 2 of 23 , Mar 11, 2014
        Alexander Shukaev wrote:
        > Hey everyone,
        >
        > Vim for Windows [https://bitbucket.org/Haroogan/vim-for-windows%5d has been updated to 7.4.193. Starting from this release, the support for the latest Lua (5.2) has been included.
        ----
        Um... you seemed to have missed including perl all-together.
        You got Ruby, Lua but you have *two* versions of python. Shouldn't
        one of those been perl? ;-)?

        I think perl 5.16.3 would be a safe choice:
        IMO, perl-5.18 has incompatibilities w/existing code.

        (New feature, "experimental warnings", is forced on,
        by default (even if you haven't enabled warnings) and 5.18
        changed a previous feature into experimental -- thus causing
        any code using what was previously a stable feature to now
        get runtime warnings. This causes problems with code that
        used to work before 5.18. In some cases, programs won't run
        at all.)

        Since perl-5.18 is, by default, incompatible without changing the
        source of old programs, I'd suggest 5.16.3 to be a safer choice.



        --
        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/d/optout.
      • Alexander Shukaev
        Dear Linda, It feels like Perl is not very trendy these days. Support for that many languages was added because certain popular plugins are written partly (or
        Message 3 of 23 , Mar 11, 2014
          Dear Linda,

          It feels like Perl is not very trendy these days. Support for that many languages was added because certain popular plugins are written partly (or fully) in these languages rather than Vim Script. Python is probably the most popular language for extending Vim right now, perhaps after Vim Script. Ruby goes next, then Lua. But I've never came across a single plugin which would rely on Perl to be honest. May I ask why you think that Perl is so important for that Vim distribution?

          Regards,
          Alexander

          --
          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/d/optout.
        • Linda W
          ... Trendy? How _trendy_ is international support? International and perl support were the first things to be provided as optional modules not because they
          Message 4 of 23 , Mar 13, 2014
            Alexander Shukaev wrote:
            > Dear Linda,
            >
            > It feels like Perl is not very trendy these days.
            Trendy? How _trendy_ is international support? International and perl
            support were the first things to be provided as optional modules not because
            they were trendy, but considered essential. Perl is usually used for
            'plumbing' type tasks. It hooks things together and can transform them.
            However, it's hard to consider 'plumbing' trendy -- but one wouldn't build
            a house w/o plumbing because it isn't 'trend'.


            But you say you haven't seen much in perl+vim -- how have you looked?
            I tried searching for vim plugins and scripts and adjuncts on
            "search.cpan.org". I came up with about 270 hits. Among those are
            things that provide vim functionality to create IDE's debuggers,
            packages, use for wiki creation to do LaTex typesetting from vim, website
            creation addons, and tons of system administration scripts. Computer
            system administration isn't very trendy -- but without it, you'd have
            nothing you are using today. No internet, no world connections, no
            trends except what are set by the large corporations...

            Maybe "utility" or "usefulness" should be considered before trendy (or
            at least, as well)? How many filters can you write in python, without
            using a separate file? Or -- more precisely, how many python 1-liners
            can people easily write and use? Does python even have an option to
            execute a line of code from the command line or use it as a filter?

            What is the option in python to write and execute a line of code?
            Can you write a 1 line python filter capitalizes all occurrences of
            your name and replace all occurances of :-) with their unicode
            equivalent, of a white smiling face (☺) using it's name "white
            smiling face" .. could you do it in any of the languages you mention?
            You can in perl. It's the only language that has full unicode support.


            Isn't multicore/multithreaded, 'Trendy'?

            Recently someone did a program to test timekeeping in python. It used
            9 threads. I completed in 67.35 seconds using 181.94% cpu (100%=1 core,
            so 1.82 cores on a 12 core machine.

            As a curiosity I wrote the exact same program in perl to see how it would
            perform (cuz I thought the MD5sum was slow)... I was turned on my head.

            Same** program in perl took 3.36 seconds using 870% cpu.

            **-I didn't use any perl tricks -- I tried to follow the python
            example as closely as possible (to see code for each, and
            compare, see http://www.perlmonks.org/?node_id=1076596).

            So for the 9 threads:

            lang #thrds #cores_used %efficency clocktime cputime(Usr+Sys)
            python 9 1.82 20.2% 67.35s 122.53s
            perl 9 8.70 96.7% 3.36s 29.23

            From the above, stated as percentages or multipliers,
            perl is 478% more efficient in making use of multicore resources.

            In real time, python takes 64 seconds longer over the base time
            that was needed, of 3.36s. Python is 1900% SLOWER.

            Someone mentioned python might not be optimal in parallelism due to
            threading problems.

            So look at the actual amount of CPUtime used for each to do the work.
            122.53/29.23. For heavy number crunching, perl (with max precision
            possible in x86-64 HW, takes less than 1/4th the time, i.e. perl
            is 4.2x the speed of python.

            Python may be trendy, but for getting actual work done, perl is not
            only considerably faster, but has most all the libraries needed to do
            it's work *built-in*. -- know wondering about what to 'import'.

            I could go on for WAY too long, on this, but lets look at who *sets*
            the trends...

            The most complicated and central function in text processing -- the
            regular expression.

            Did python choose posix RE or extended RE syntax? Nope.
            javascript and python and most modern languages have copied the
            perl's regex syntax and features -- and note-- perl has no problem
            trying to make things *easier* for python developers. When
            perl implemented named subexpressions or captures in Regex's, in
            addition to the perl syntax, the Python syntax as added as well
            to make things easier for those familiar with that syntax.

            Perl's Regex engine has been described as the 'best of breed' --
            with java, javascript, ruby, python et al, all adopting the
            Regex syntax developed in Perl.

            If it wasn't for the groundwork laid by perl, you wouldn't be
            doing scripting in the other languages you are today -- as
            they would have had to develop, "at least_, their own regex engine.

            So ok, the other languages are more trendy -- but many are where
            they are at today because of groundwork laid by perl.

            Aside from that, you are not really including the languages (are you?)
            Aren't they DLL's that are loaded if present and not loaded if not
            used? Are you providing the DLL's for each language? Usually, what
            is added is the ability to load the DLL if it is present. So really,
            you don't need to include perl -- just the ability to make use of it
            at run time if it is present, right? Or did you really link all of
            those languages in with your vim binary? If that's the case...
            then that's a bigger problem.

            For most (all -- not sure about LUA) of those languages, the actual
            support for them is in an external library -- so
            the users don't actually 'pay' for the languages they don't use as they
            are not loaded and -- if they don't use them -- they don't even need to be
            on their machine.

            > Support for that many languages was added because certain popular
            > plugins are written partly (or fully) in these languages rather than
            > Vim Script. Python is probably the most popular language for extending
            > Vim right now, perhaps after Vim Script. Ruby goes next, then Lua. But
            > I've never came across a single plugin which would rely on Perl to be
            > honest. May I ask why you think that Perl is so important for that Vim
            > distribution?

            #2 on the list for http://www.vim.org/sponsor/vote_results.php.
            was an IDE. You should check out:. https://metacpan.org/release/Vim-Debug.

            It's already been done for perl and from the documentation it should be
            extensible to other languages.. But it IS written in perl...

            So you honestly didn't come across a single plugin that would rely on perl?
            Where did you look?







            --
            --
            You received this message from the "vim_use" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/d/optout.
          • tooth pik
            ... nice rant, Linda, bravo! but all this and no mention of CPAN, while we vim children squabble over the best plugin manager I think python gets picked over
            Message 5 of 23 , Mar 13, 2014
              On Thu, Mar 13, 2014 at 05:16:04AM -0700, Linda W wrote:
              > Alexander Shukaev wrote:
              > >Dear Linda,
              > >
              > >It feels like Perl is not very trendy these days.
              > Trendy? How _trendy_ is international support? International and perl
              > support were the first things to be provided as optional modules not because
              > they were trendy, but considered essential. Perl is usually used for
              > 'plumbing' type tasks. It hooks things together and can transform
              > them. However, it's hard to consider 'plumbing' trendy -- but one
              > wouldn't build
              > a house w/o plumbing because it isn't 'trend'.


              > But you say you haven't seen much in perl+vim -- how have you looked?
              > I tried searching for vim plugins and scripts and adjuncts on
              > "search.cpan.org". I came up with about 270 hits. Among those are
              > things that provide vim functionality to create IDE's debuggers,
              > packages, use for wiki creation to do LaTex typesetting from vim, website
              > creation addons, and tons of system administration scripts. Computer
              > system administration isn't very trendy -- but without it, you'd have
              > nothing you are using today. No internet, no world connections, no
              > trends except what are set by the large corporations...

              > Maybe "utility" or "usefulness" should be considered before trendy (or
              > at least, as well)? How many filters can you write in python, without
              > using a separate file? Or -- more precisely, how many python 1-liners
              > can people easily write and use? Does python even have an option
              > to execute a line of code from the command line or use it as a
              > filter?

              > What is the option in python to write and execute a line of code?
              > Can you write a 1 line python filter capitalizes all occurrences of
              > your name and replace all occurances of :-) with their unicode
              > equivalent, of a white smiling face (☺) using it's name "white
              > smiling face" .. could you do it in any of the languages you mention?
              > You can in perl. It's the only language that has full unicode support.


              > Isn't multicore/multithreaded, 'Trendy'?

              > Recently someone did a program to test timekeeping in python. It used
              > 9 threads. I completed in 67.35 seconds using 181.94% cpu (100%=1 core,
              > so 1.82 cores on a 12 core machine.

              > As a curiosity I wrote the exact same program in perl to see how it would
              > perform (cuz I thought the MD5sum was slow)... I was turned on my head.

              > Same** program in perl took 3.36 seconds using 870% cpu.

              > **-I didn't use any perl tricks -- I tried to follow the python
              > example as closely as possible (to see code for each, and
              > compare, see http://www.perlmonks.org/?node_id=1076596).

              > So for the 9 threads:

              > lang #thrds #cores_used %efficency clocktime cputime(Usr+Sys)
              > python 9 1.82 20.2% 67.35s 122.53s
              > perl 9 8.70 96.7% 3.36s 29.23

              > From the above, stated as percentages or multipliers,
              > perl is 478% more efficient in making use of multicore resources.

              > In real time, python takes 64 seconds longer over the base time
              > that was needed, of 3.36s. Python is 1900% SLOWER.

              > Someone mentioned python might not be optimal in parallelism due to
              > threading problems.

              > So look at the actual amount of CPUtime used for each to do the work.
              > 122.53/29.23. For heavy number crunching, perl (with max precision
              > possible in x86-64 HW, takes less than 1/4th the time, i.e. perl
              > is 4.2x the speed of python.

              > Python may be trendy, but for getting actual work done, perl is not
              > only considerably faster, but has most all the libraries needed to do
              > it's work *built-in*. -- know wondering about what to 'import'.

              > I could go on for WAY too long, on this, but lets look at who *sets*
              > the trends...

              > The most complicated and central function in text processing -- the
              > regular expression.

              > Did python choose posix RE or extended RE syntax? Nope.
              > javascript and python and most modern languages have copied the
              > perl's regex syntax and features -- and note-- perl has no problem
              > trying to make things *easier* for python developers. When
              > perl implemented named subexpressions or captures in Regex's, in
              > addition to the perl syntax, the Python syntax as added as well
              > to make things easier for those familiar with that syntax.

              > Perl's Regex engine has been described as the 'best of breed' --
              > with java, javascript, ruby, python et al, all adopting the
              > Regex syntax developed in Perl.

              > If it wasn't for the groundwork laid by perl, you wouldn't be
              > doing scripting in the other languages you are today -- as
              > they would have had to develop, "at least_, their own regex engine.

              > So ok, the other languages are more trendy -- but many are where
              > they are at today because of groundwork laid by perl.

              > Aside from that, you are not really including the languages (are you?)
              > Aren't they DLL's that are loaded if present and not loaded if not
              > used? Are you providing the DLL's for each language? Usually, what
              > is added is the ability to load the DLL if it is present. So really,
              > you don't need to include perl -- just the ability to make use of it
              > at run time if it is present, right? Or did you really link all of
              > those languages in with your vim binary? If that's the case...
              > then that's a bigger problem.

              > For most (all -- not sure about LUA) of those languages, the actual
              > support for them is in an external library -- so
              > the users don't actually 'pay' for the languages they don't use as they
              > are not loaded and -- if they don't use them -- they don't even need to be
              > on their machine.

              > >Support for that many languages was added because certain popular
              > >plugins are written partly (or fully) in these languages rather
              > >than Vim Script. Python is probably the most popular language for
              > >extending Vim right now, perhaps after Vim Script. Ruby goes next,
              > >then Lua. But I've never came across a single plugin which would
              > >rely on Perl to be honest. May I ask why you think that Perl is so
              > >important for that Vim distribution?

              > #2 on the list for http://www.vim.org/sponsor/vote_results.php.
              > was an IDE. You should check out:. https://metacpan.org/release/Vim-Debug.

              > It's already been done for perl and from the documentation it should
              > be extensible to other languages.. But it IS written in perl...

              > So you honestly didn't come across a single plugin that would rely on perl?
              > Where did you look?

              nice rant, Linda, bravo!

              but all this and no mention of CPAN, while we vim children squabble
              over the best plugin manager

              I think python gets picked over perl because of all the bad and
              obfuscated perl code that's been written over the years and it just
              scares people

              --
              _|_ _ __|_|_ ._ o|
              |_(_)(_)|_| ||_)||<
              |

              --
              --
              You received this message from the "vim_use" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/d/optout.
            • Linda W
              ... Nice read... I see how well you got the salient points.... Rant? That s going off on on a mostly emotional response vs. presenting facts, figures,
              Message 6 of 23 , Mar 13, 2014
                tooth pik wrote:
                >
                >> I tried searching for vim plugins and scripts and adjuncts on
                >>
                >> "search.cpan.org".
                >>
                >> I came up with about 270 hits. Among those are
                >> things that provide vim functionality to create IDE's debuggers,
                >> packages, use for wiki creation to do LaTex typesetting from vim, website
                >> creation addons, and tons of system administration scripts.
                > nice rant, Linda, bravo!
                >
                ----
                > but all this and no mention of CPAN, while we vim children squabble
                > over the best plugin manage
                ----
                Nice read... I see how well you got the salient points....

                Rant? That's going off on on a mostly emotional response vs.
                presenting facts, figures, examples and comparisons. Could you
                describe why you'd call a research thesis a rant?

                It's not like I wrote it on a whim. Rants don't usually cite multiple
                sources.





                --
                --
                You received this message from the "vim_use" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/d/optout.
              • Alexander Shukaev
                I m afraid you overextended the topic. Now, let s try to filter what you ve presented with a cool head. I ve never said Perl is bad or anything like that.
                Message 7 of 23 , Mar 13, 2014
                  I'm afraid you overextended the topic. Now, let's try to filter what you've presented with a cool head.

                  I've never said Perl is bad or anything like that. Every language has its own niche. The point was that many modern and very popular plugins these days are not written in Perl. That's what I meant by "trendy". Did you look through those 270 hits? Who uses those plugins? Or are they simply outdated legacy? I have tens of thousands of downloads of this Vim distribution and every user is free to create an issue to request something. I was requested Lua, for example. But nobody ever complained about the lack of Perl, and most likely because nobody cares about it, as nobody uses any plugins relying on it or does command-line scripting with it.

                  All the talks about the parallelism are beyond the scope of the Vim context discussion. They also seem to be a bit exaggerated in a way that I start to think that you are Perl fan, and that you are more to defend Perl on a whole, rather than discuss its importance in modern Vim. The efficiency of parallel code depends on lots of factors, the ones that you never even thought about, so again, I'd drop this topic from our discussion.

                  The fact that many other languages inherited something from Perl is true, and I've never claimed against it. But once again, that does support the main topic of our discussion. I could say that Java inherited a lot from C/C++, nevertheless Java still solves a great deal of problems (on modern market) much better than C/C++. Does that mean that I should prefer Java over C/C++? No, because at the same time C/C++ excel in other areas, and I'd rather choose the language according to its purpose and my requirements. In any case, this is again off topic.

                  There are plenty of debugger integrations for Vim out there, and therefore reasoning that IDE request is #2, and that just one of its aspects, debugger facility, was written in Perl is quite weak argument, and the connection is rather indirect.

                  I didn't expect this discussion to go into the realm of language clashes. I'm speaking from the point of view of raw numbers: who uses what and how many. Perl is far not on the top of language preferences for plugins these days. I'll be honest with you, I also don't like some points about Python for example, and maybe Perl is indeed better for certain goals. But the question is not about my or your subjective opinions. I'm trying to reason objectively when I prepare these distributions, i.e. I ask myself a question what other people need? That brings to the question: what is trendy? Which plugins people tend to use more? What is required from Vim distribution to support them? For instance, currently, it's hard to imagine useful Vim distribution without both versions of Python 2 and 3.
                   
                  And no, I didn't link against shared libraries because that makes no sense. Can you give me a link to some very popular plugin which is written in Perl, and so that I could see that it is indeed used by many people, i.e. proof like downloads number or stars on GitHub or votes, etc. Proof with raw numbers is always worth a thousand words, otherwise your statements risk to be regarded as rant. Anyway, thanks for sharing your thoughts.

                  Regards,
                  Alexander

                  --
                  --
                  You received this message from the "vim_use" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/d/optout.
                • Linda W
                  ... I don t think I claimed you said that -- you said it wasn t trendy. I ... Since perl and cpan is distributed via a network of 100 s of mirrors -- there is
                  Message 8 of 23 , Mar 13, 2014
                    Alexander Shukaev wrote:
                    > I'm afraid you overextended the topic. Now, let's try to filter what
                    > you've presented with a cool head.
                    >
                    > I've never said Perl is bad or anything like that.
                    ----
                    I don't think I claimed you said that -- you said it wasn't trendy. I
                    > Every language has its own niche. The point was that many modern and
                    > very popular plugins these days are not written in Perl. That's what I
                    > meant by "trendy". Did you look through those 270 hits? Who uses those
                    > plugins? Or are they simply outdated legacy? I have tens of thousands
                    > of downloads of this Vim distribution.
                    ----
                    Since perl and cpan is distributed via a network of 100's of mirrors
                    -- there is no easy way to keep a central accounting. It wasn't
                    practical to keep it in one place where one could count the number of
                    downloads because the bandwidth costs when perl was developed, were
                    prohibitive. That hasn't changed that much. I have used some of those
                    scripts so I know they aren't outdated legacy, but vim was too slow
                    parsing all of the vim-script related to using those plugins, so I
                    stopped using it. The problem is that vim parses all of the setups of
                    those scripts each
                    time it starts, whether those things are used or not. Most of the time
                    I'm not using
                    a perl debugger, so it wasn't practical the way the vim scripts were
                    setup.

                    > ...and every user is free to create an issue to request something. I
                    > was requested Lua, for example.
                    You were also requested perl -- BUT...
                    > But nobody ever complained about the lack of Perl, and most likely
                    > because nobody cares about it, as nobody uses any plugins relying on
                    > it or does command-line scripting with it.

                    > There are plenty of debugger integrations for Vim out there, and
                    > therefore reasoning that IDE request is #2, and that just one of its
                    > aspects, debugger facility, was written in Perl is quite weak
                    > argument, and the connection is rather indirect.
                    It's not a debugger facility -- it's an IDE. keyword completion,
                    refactoring code,
                    reformatting, but there are better perl IDE's out there, so it probably
                    isn't used as much
                    anymore.
                    > And no, I didn't link against shared libraries because that makes no
                    > sense.
                    ----
                    This makes the discussion mostly moot. I wasn't arguing or wanting a
                    vim w/all of them linked in, but the version that looks for all of them
                    dynamically
                    they way it has historically done.

                    I'm used to the vim's that were built with run-time dynamic loading
                    of available
                    libraries. It doesn't cost anything to include the hooks for loading --
                    but if you are
                    linking all of them in... *ouch*. It used to be the case that the
                    Windows version was
                    the best example of using DLL's -- because if you wanted one of the
                    languages,
                    you provided a standard DLL, and vim would load it the first time you
                    tried to use
                    the language. If you never used it, it never looked for it.

                    The cost for adding each language is about 1.5M... The version with
                    all the languages
                    bound in is about 8.1M. The version with them dynamically loaded is 2.1M.

                    If you are creating a version with them all linked in, then I can't
                    justify including
                    perl as I wouldn't use such a version. I thought you were using the
                    version w/hooks
                    for each of the languages. They *run* the same except the dynamic one loads
                    considerably faster and only loads the languages you actually use the
                    first time it is
                    used.

                    Sorry for my misunderstanding.



                    --
                    --
                    You received this message from the "vim_use" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_use" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                    For more options, visit https://groups.google.com/d/optout.
                  • Alexander Shukaev
                    I m NOT linking shared libraries of side languages to Vim. They are loaded dynamically on demand and if appropriate versions of them are present on your
                    Message 9 of 23 , Mar 13, 2014
                      I'm NOT linking shared libraries of side languages to Vim. They are loaded dynamically on demand and if appropriate versions of them are present on your machine. There are no explicit dependencies of my Vim distribution to any of third party shared libraries.

                      --
                      --
                      You received this message from the "vim_use" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_use" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                      For more options, visit https://groups.google.com/d/optout.
                    • Linda W
                      ... Then what is the cost to anyone to add perl to that list? You don t have to have it on your machine. The user has to provide the third party library --
                      Message 10 of 23 , Mar 13, 2014
                        Alexander Shukaev wrote:
                        > I'm NOT linking shared libraries of side languages to Vim. They are
                        > loaded dynamically on demand and if appropriate versions of them are
                        > present on your machine. There are no explicit dependencies of my Vim
                        > distribution to any of third party shared libraries.
                        ----
                        Then what is the cost to anyone to add perl to that list? You don't
                        have to have it
                        on your machine. The user has to provide the third party library -- if
                        they want
                        any of the languages {ruby, perl, python{2,3},lua}, then they can supply
                        the 3rd
                        party libs.

                        So what extra cost is it to you to *allow* a 3rd party lib to be
                        loaded. I.e.
                        it's not that you are providing these languages but are deciding what
                        languages people
                        can supply at runtime to use with it. You decided to disallow perl
                        because it isn't
                        trendy enough?

                        What do you have against perl? Since the cost of the hooks are
                        negligible, what
                        possible reason could you have for NOT **allowing** the user to use the
                        library
                        that they provide -- same as for python, lua and ruby?


                        --
                        --
                        You received this message from the "vim_use" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_use" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                        For more options, visit https://groups.google.com/d/optout.
                      • Tony Mechelynck
                        On 13/03/14 16:24, Alexander Shukaev wrote: [...] ... Linking dynamically against libraries to be loaded or not depending on their presence at run-time makes
                        Message 11 of 23 , Mar 13, 2014
                          On 13/03/14 16:24, Alexander Shukaev wrote:
                          [...]
                          > And no, I didn't link against shared libraries because that makes no
                          > sense. [...]

                          Linking dynamically against libraries to be loaded or not depending on
                          their presence at run-time makes every sense for an executable which is
                          not (or not only) for your own personal use but for distribution to
                          various users with diverse likes and needs:
                          - Each of these libraries is available for the user who needs them
                          - Users who don't need them don't have to have them installed
                          - None of these libraries are included in the executable itself,
                          reducing bloat gigantically.
                          - Do I have to go on? It never surprised me that Steve Hall tried to
                          include all possible language interfaces in his "Vim without Cream", and
                          that, without exception, all of them that he did include were included
                          dynamically. The latest version (7.4.187) has +lua/dyn -mzscheme
                          +perl/dyn +python/dyn +python3/dyn +ruby/dyn -tcl — and I'm sure that
                          the lack of mzscheme and tcl is not for lack of "trendiness" but only
                          because Steve couldn't get them to work.

                          Some people, and, alas, some developers, think that everyone has the
                          same preferences they do, and that therefore anything they don't use
                          themselves is «used by nobody» — and conversely, that everything they do
                          use themselves is «used by everybody» and doesn't need to be made
                          optional. Nothing (for me it is "of course" but maybe for you it isn't
                          that obvious) could be farther from reality. People are a motley bunch,
                          and there are people out there for whom something that you wouldn't
                          touch with a ten-foot pole is in the "can't live without" category, and
                          others who wouldn't touch what you can't live without, even if you paid
                          them for it. Is it so difficult to humor them all when you build
                          software «for everyone»?

                          And no, as Linda said, plumbing isn't "trendy". Maybe that's why it's so
                          hard to find a plumber when, on a Sunday morning (these things always
                          happen on Sunday mornings of course) my toilet starts throwing water and
                          shit all over the place, or the water mains starts pissing on my kitchen
                          wall. But when either of these happens, trendy or not, Sunday morning or
                          not, I know what kind of craftsman I need, and I need him HERE NOW.


                          Best regards,
                          Tony.
                          --
                          hundred-and-one symptoms of being an internet addict:
                          100. The most exciting sporting events you noticed during summer 1996
                          was Netscape vs. Microsoft.

                          --
                          --
                          You received this message from the "vim_use" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_use" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                          For more options, visit https://groups.google.com/d/optout.
                        • Alexander Shukaev
                          Tony, linking against shared library means to have an explicit dependency to it. I m NOT (god, how many more times should I explain this) linking third party
                          Message 12 of 23 , Mar 14, 2014
                            Tony, linking against shared library means to have an explicit dependency to it. I'm NOT (god, how many more times should I explain this) linking third party shared libraries DIRECTLY to Vim! They are dynamically loaded (what you call "dynamically linked") with a system call when they are needed and if users has them on their system. It's user's responsibility to download and install properly third party software. I'm nether distribution third party libraries with Vim, neither I force users to have them (what would have been the case, if I would be linking them directly to Vim).

                            So when I say, "And no, I didn't link against shared libraries because that makes no sense." - is it only me who instantly understands that this phrase summarizes the whole paragraph above or you guys prefer to interpret "didn't link" as "did link" (3 times already) just to piss me off?

                            --
                            --
                            You received this message from the "vim_use" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php

                            ---
                            You received this message because you are subscribed to the Google Groups "vim_use" group.
                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                            For more options, visit https://groups.google.com/d/optout.
                          • Tony Mechelynck
                            ... OK, so what you call linking with shared libraries is actually linking statically with libraries which may (or may not) be included in the final
                            Message 13 of 23 , Mar 14, 2014
                              On 14/03/14 09:04, Alexander Shukaev wrote:
                              > Tony, linking against shared library means to have an explicit
                              > dependency to it. I'm NOT (god, how many more times should I explain
                              > this) linking third party shared libraries DIRECTLY to Vim! They are
                              > dynamically loaded (what you call "dynamically linked") with a system
                              > call when they are needed and if users has them on their system. It's
                              > user's responsibility to download and install properly third party
                              > software. I'm nether distribution third party libraries with Vim,
                              > neither I force users to have them (what would have been the case, if I
                              > would be linking them directly to Vim).
                              >
                              > So when I say, "And no, I didn't link against shared libraries because
                              > that makes no sense." - is it only me who instantly understands that
                              > this phrase summarizes the whole paragraph above or you guys prefer to
                              > interpret "didn't link" as "did link" (3 times already) just to piss me off?

                              OK, so what you call "linking with shared libraries" is actually linking
                              statically with libraries which may (or may not) be included in the
                              final executable, in which case you don't share them with anyone.
                              Dynamically linked libraries are always shared (when used). You never
                              used the all-important adverb "statically" so we understood that your
                              "shared libraries" were "dynamically-linked libraries", which, unlike
                              statically-linked ones, are always shared.


                              Best regards,
                              Tony.
                              --
                              "Obviously, a major malfunction has occurred."
                              -- Steve Nesbitt, voice of Mission Control, January 28,
                              1986, as the shuttle Challenger exploded within view
                              of the grandstands.

                              --
                              --
                              You received this message from the "vim_use" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php

                              ---
                              You received this message because you are subscribed to the Google Groups "vim_use" group.
                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                              For more options, visit https://groups.google.com/d/optout.
                            • Alexander Shukaev
                              It s actually vice versa... Linking A (what you call statically , i.e. linking against static import library corresponding to DLL B) against a DLL B means
                              Message 14 of 23 , Mar 14, 2014
                                It's actually vice versa... Linking A (what you call "statically", i.e. linking against static import library corresponding to DLL B) against a DLL B means that you add automatic explicit dynamic runtime dependency of A to B. The code of DLL B is not compiled into A, only a small code snippet that "A, as soon as it starts, should automatically search and load its dependency B, and if not present, then throw error" is automatically injected by compiler into A. I emphasize, this is what is called "to link against DLL/shared library".

                                "To dynamically load/link DLL/shared library" is when you manually make a system in call in the code of A to load B, and you yourself control when and why you do it. This way, there is not automatic explicit runtime dependency of A to B, and therefore it is not strictly required to distribute B with A. My Vim distributions use this 2nd approach, and that's why "And no, I didn't link against shared libraries because that makes no sense." implies exactly that.

                                --
                                --
                                You received this message from the "vim_use" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php

                                ---
                                You received this message because you are subscribed to the Google Groups "vim_use" group.
                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                For more options, visit https://groups.google.com/d/optout.
                              • LCD 47
                                ... [...] No. What he means by linking with shared libraries seems to be a Windows incarnation of dlopen(3). That isn t linking in the usual sense, the
                                Message 15 of 23 , Mar 14, 2014
                                  On 14 March 2014, Tony Mechelynck <antoine.mechelynck@...> wrote:
                                  > On 14/03/14 09:04, Alexander Shukaev wrote:
                                  > >Tony, linking against shared library means to have an explicit
                                  > >dependency to it. I'm NOT (god, how many more times should I explain
                                  > >this) linking third party shared libraries DIRECTLY to Vim! They are
                                  > >dynamically loaded (what you call "dynamically linked") with a system
                                  > >call when they are needed and if users has them on their system. It's
                                  > >user's responsibility to download and install properly third party
                                  > >software. I'm nether distribution third party libraries with Vim,
                                  > >neither I force users to have them (what would have been the case, if
                                  > >I would be linking them directly to Vim).
                                  > >
                                  > >So when I say, "And no, I didn't link against shared libraries
                                  > >because that makes no sense." - is it only me who instantly
                                  > >understands that this phrase summarizes the whole paragraph above or
                                  > >you guys prefer to interpret "didn't link" as "did link" (3 times
                                  > >already) just to piss me off?
                                  >
                                  > OK, so what you call "linking with shared libraries" is actually
                                  > linking statically with libraries which may (or may not) be included
                                  > in the final executable, in which case you don't share them with
                                  > anyone.
                                  [...]

                                  No. What he means by "linking with shared libraries" seems to be
                                  a Windows incarnation of dlopen(3). That isn't linking in the usual
                                  sense, the more common name for it would be "demand loading".

                                  http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html

                                  /lcd

                                  --
                                  --
                                  You received this message from the "vim_use" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php

                                  ---
                                  You received this message because you are subscribed to the Google Groups "vim_use" group.
                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                  For more options, visit https://groups.google.com/d/optout.
                                • Alexander Shukaev
                                  It seems like there is too much confusion about the terms. I just want to make it clear with obvious examples because describing it with words seems to only
                                  Message 16 of 23 , Mar 14, 2014
                                    It seems like there is too much confusion about the terms. I just want to make it clear with obvious examples because describing it with words seems to only worsen the confusion.

                                    `gcc vim.o python33.dll -o vim` is linking `vim` against `python33.dll` at compile time, i.e. introducing automatic explicit dependency of `vim` to `python33.dll`. In this case, to start `vim` users would be forced to have `python33.dll` or get error otherwise.

                                    `LoadLibrary("python33")` (on Windows) or `dlopen("python33", RTLD_NOW)` (on Unix) is dynamically loading `python33.dll` or `libpython33.so` by `vim`, i.e. not introducing automatic explicit dependency of `vim` to `python33.dll` or `libpython33.so`. In this case, to start `vim` users are not forced to have `python33.dll`  or `libpython33.so`, but if they have one, it will be loaded by this system call and Python would be usable from Vim.

                                    Do you call these 2 approaches of shared library/DLL management the other way around?

                                    --
                                    --
                                    You received this message from the "vim_use" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php

                                    ---
                                    You received this message because you are subscribed to the Google Groups "vim_use" group.
                                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                    For more options, visit https://groups.google.com/d/optout.
                                  • LCD 47
                                    ... (1) Static linking: gcc -o vim vim.o libpython33.a - on UNIX gcc -o vim.exe vim.obj python33.lib - on Windows (2) Dinamyc linking: gcc -o vim
                                    Message 17 of 23 , Mar 14, 2014
                                      On 14 March 2014, Alexander Shukaev <haroogan@...> wrote:
                                      > It seems like there is too much confusion about the terms. I just want to
                                      > make it clear with obvious examples because describing it with words seems
                                      > to only worsen the confusion.
                                      >
                                      > `gcc vim.o python33.dll -o vim` is linking `vim` against `python33.dll` at
                                      > compile time, i.e. introducing automatic explicit dependency of `vim` to
                                      > `python33.dll`. In this case, to start `vim` users would be forced to have
                                      > `python33.dll` or get error otherwise.
                                      >
                                      > `LoadLibrary("python33")` (on Windows) or `dlopen("python33", RTLD_NOW)`
                                      > (on Unix) is dynamically loading `python33.dll` or `libpython33.so` by
                                      > `vim`, i.e. not introducing automatic explicit dependency of `vim` to
                                      > `python33.dll` or `libpython33.so`. In this case, to start `vim` users are
                                      > not forced to have `python33.dll` or `libpython33.so`, but if they have
                                      > one, it will be loaded by this system call and Python would be usable from
                                      > Vim.
                                      >
                                      > Do you call these 2 approaches of shared library/DLL management the other
                                      > way around?

                                      (1) Static linking:

                                      gcc -o vim vim.o libpython33.a - on UNIX
                                      gcc -o vim.exe vim.obj python33.lib - on Windows

                                      (2) Dinamyc linking:

                                      gcc -o vim vim.o libpython33.so - on UNIX
                                      gcc -o vim.exe vim.obj python33.dll - on Windows

                                      (3) Demand loading, nothing to do with linking:

                                      dlopen("python33", RTLD_NOW) - on UNIX
                                      LoadLibrary("python33") - on Windows

                                      /lcd

                                      --
                                      --
                                      You received this message from the "vim_use" maillist.
                                      Do not top-post! Type your reply below the text you are replying to.
                                      For more information, visit http://www.vim.org/maillist.php

                                      ---
                                      You received this message because you are subscribed to the Google Groups "vim_use" group.
                                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                      For more options, visit https://groups.google.com/d/optout.
                                    • LCD 47
                                      ... s/Dinamyc/Dynamic/ /lcd -- -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to.
                                      Message 18 of 23 , Mar 14, 2014
                                        On 14 March 2014, LCD 47 <lcd047@...> wrote:
                                        > (2) Dinamyc linking:

                                        s/Dinamyc/Dynamic/

                                        /lcd

                                        --
                                        --
                                        You received this message from the "vim_use" maillist.
                                        Do not top-post! Type your reply below the text you are replying to.
                                        For more information, visit http://www.vim.org/maillist.php

                                        ---
                                        You received this message because you are subscribed to the Google Groups "vim_use" group.
                                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                        For more options, visit https://groups.google.com/d/optout.
                                      • Linda W
                                        ... Confusing the issue is that shared libraries can be linked statically or dynamically. private libraries are almost always (I don t know of any exceptions
                                        Message 19 of 23 , Mar 14, 2014
                                          Alexander Shukaev wrote:
                                          > It seems like there is too much confusion about the terms. I just want
                                          > to make it clear with obvious examples because describing it with
                                          > words seems to only worsen the confusion.
                                          >
                                          > `gcc vim.o python33.dll -o vim` is linking `vim` against
                                          > `python33.dll` at compile time, i.e. introducing automatic explicit
                                          > dependency of `vim` to `python33.dll`. In this case, to start `vim`
                                          > users would be forced to have `python33.dll` or get error otherwise.
                                          >
                                          > `LoadLibrary("python33")` (on Windows) or `dlopen("python33",
                                          > RTLD_NOW)` (on Unix) is dynamically loading `python33.dll` or
                                          > `libpython33.so` by `vim`, i.e. not introducing automatic explicit
                                          > dependency of `vim` to `python33.dll` or `libpython33.so`. In this
                                          > case, to start `vim` users are not forced to have `python33.dll` or
                                          > `libpython33.so`, but if they have one, it will be loaded by this
                                          > system call and Python would be usable from Vim.
                                          >
                                          > Do you call these 2 approaches of shared library/DLL management the
                                          > other way around?
                                          > ----

                                          Confusing the issue is that shared libraries can be linked statically or
                                          dynamically.

                                          private libraries are almost always (I don't know of any exceptions off
                                          hand) linked statically.

                                          I think I understand that you are using the feature that was used first
                                          used with the iconv library and the perl.so library. It was later
                                          expanded to include trendier languages, but why would you disable the
                                          choice for anything but your own private version?? If you are
                                          developing a distribution for the community, to do the best for that
                                          community, you would turn on all of the "run-time" loadable languages
                                          and features that you could and let the community users decide how to
                                          make use of that resource.

                                          I asked the question -- since you are not linking the libraries in
                                          statically, then you aren't
                                          introducing any "load-time" dependencies, so why not just allow anything
                                          that vim can load to be loaded? So why disable hooks that are
                                          already there?




                                          --
                                          --
                                          You received this message from the "vim_use" maillist.
                                          Do not top-post! Type your reply below the text you are replying to.
                                          For more information, visit http://www.vim.org/maillist.php

                                          ---
                                          You received this message because you are subscribed to the Google Groups "vim_use" group.
                                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                          For more options, visit https://groups.google.com/d/optout.
                                        • Alexander Shukaev
                                          They are not already there. One still has to do some work to enable all these languages. One needs some of their header files to be built with Vim. So one have
                                          Message 20 of 23 , Mar 14, 2014
                                            They are not already there. One still has to do some work to enable all these languages. One needs some of their header files to be built with Vim. So one have to get some version of their distribution and compile their headers (and sometimes some other stuff) with Vim. So I didn't disable anything, it's just that at current point I've managed to successfully build Vim for x86 and x64 with Python, Ruby, and Lua. I haven't even looked into Perl yet and I don't know whether I'll have problems with it especially on x64. That's why I'm asking if there is really any need for Perl? If yes, then I'll look into it for the next release. Seriously, that's it.

                                            --
                                            --
                                            You received this message from the "vim_use" maillist.
                                            Do not top-post! Type your reply below the text you are replying to.
                                            For more information, visit http://www.vim.org/maillist.php

                                            ---
                                            You received this message because you are subscribed to the Google Groups "vim_use" group.
                                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                            For more options, visit https://groups.google.com/d/optout.
                                          • Alexander Shukaev
                                            Also, it s not that I ve planned to develop anything for community. It was just a fact that I ve (probably) pioneered building 64-bit version of Vim for
                                            Message 21 of 23 , Mar 14, 2014
                                              Also, it's not that I've planned to develop anything for community. It was just a fact that I've (probably) pioneered building 64-bit version of Vim for Windows with support for both Python 2 and Python 3 simultaneously. I guess for others it simply wouldn't compile because it had to actually be patched in some aspects. I uploaded it primarily for myself at first. But then it suddenly became popular. People started to ask me if I could add this and that, so I decided to provide both x64 and x86 and gradually adding support for more languages so that anyone can use it without any hassle as building Vim is really a hassle, especially for inexperienced.

                                              --
                                              --
                                              You received this message from the "vim_use" maillist.
                                              Do not top-post! Type your reply below the text you are replying to.
                                              For more information, visit http://www.vim.org/maillist.php

                                              ---
                                              You received this message because you are subscribed to the Google Groups "vim_use" group.
                                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                              For more options, visit https://groups.google.com/d/optout.
                                            • Linda W
                                              ... If you d just said it that way in the first place, I m sure there are those on the list that have build vim x64 w/perl. If not, I m using my own compiled
                                              Message 22 of 23 , Mar 14, 2014
                                                Alexander Shukaev wrote:
                                                > They are not already there. One still has to do some work to enable
                                                > all these languages. One needs some of their header files to be built
                                                > with Vim. So one have to get some version of their distribution and
                                                > compile their headers (and sometimes some other stuff) with Vim. So I
                                                > didn't disable anything, it's just that at current point I've managed
                                                > to successfully build Vim for x86 and x64 with Python, Ruby, and Lua.
                                                > I haven't even looked into Perl yet and I don't know whether I'll have
                                                > problems with it especially on x64. That's why I'm asking if there is
                                                > really any need for Perl? If yes, then I'll look into it for the next
                                                > release. Seriously, that's it.
                                                ---
                                                If you'd just said it that way in the first place, I'm sure there are
                                                those on the list that have
                                                build vim x64 w/perl. If not, I'm using my own compiled version on
                                                linux -- with python, ruby perl and maybe lua if it was an option...
                                                even though I don't use those other languages, I
                                                wouldn't want to create a limited version -- and it really is for my own
                                                use, though, I did feed
                                                back any changes changes to openSuSE, who believe it is better to static
                                                linking that requires
                                                the ".so" libraries to be present at run time, or have the user not be
                                                able to edit text, which I thought was so 'lame', (filed a bug on it and
                                                was told "thank you for sharing")... and they still create a huge
                                                monolith today.

                                                -----------------

                                                Alexander Shukaev wrote:
                                                > Also, it's not that I've planned to develop anything for community. It
                                                > was just a fact that I've (probably) pioneered building 64-bit version
                                                > of Vim for Windows with support for both Python 2 and Python 3
                                                > simultaneously. I guess for others it simply wouldn't compile because
                                                > it had to actually be patched in some aspects. I uploaded it primarily
                                                > for myself at first. But then it suddenly became popular...

                                                Sorry thought of the Marvel Comic superhero line "with great
                                                power/talent... comes great responsibilty... *cough*...*sigh*... much
                                                too late to be writing this. ;^)


                                                --
                                                --
                                                You received this message from the "vim_use" maillist.
                                                Do not top-post! Type your reply below the text you are replying to.
                                                For more information, visit http://www.vim.org/maillist.php

                                                ---
                                                You received this message because you are subscribed to the Google Groups "vim_use" group.
                                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                                For more options, visit https://groups.google.com/d/optout.
                                              • pritesh ugrankar
                                                ... Hi Linda, Found the latest version of vim at http://tuxproject.de/projects/vim/. And, only those who have run something like :%perldo
                                                Message 23 of 23 , Mar 15, 2014
                                                  On Friday, March 14, 2014 5:18:23 PM UTC+5:30, Linda W wrote:
                                                  > Alexander Shukaev wrote:
                                                  >
                                                  > > They are not already there. One still has to do some work to enable
                                                  >
                                                  > > all these languages. One needs some of their header files to be built
                                                  >
                                                  > > with Vim. So one have to get some version of their distribution and
                                                  >
                                                  > > compile their headers (and sometimes some other stuff) with Vim. So I
                                                  >
                                                  > > didn't disable anything, it's just that at current point I've managed
                                                  >
                                                  > > to successfully build Vim for x86 and x64 with Python, Ruby, and Lua.
                                                  >
                                                  > > I haven't even looked into Perl yet and I don't know whether I'll have
                                                  >
                                                  > > problems with it especially on x64. That's why I'm asking if there is
                                                  >
                                                  > > really any need for Perl? If yes, then I'll look into it for the next
                                                  >
                                                  > > release. Seriously, that's it.
                                                  >
                                                  > ---
                                                  >
                                                  > If you'd just said it that way in the first place, I'm sure there are
                                                  >
                                                  > those on the list that have
                                                  >
                                                  > build vim x64 w/perl. If not, I'm using my own compiled version on
                                                  >
                                                  > linux -- with python, ruby perl and maybe lua if it was an option...
                                                  >
                                                  > even though I don't use those other languages, I
                                                  >
                                                  > wouldn't want to create a limited version -- and it really is for my own
                                                  >
                                                  > use, though, I did feed
                                                  >
                                                  > back any changes changes to openSuSE, who believe it is better to static
                                                  >
                                                  > linking that requires
                                                  >
                                                  > the ".so" libraries to be present at run time, or have the user not be
                                                  >
                                                  > able to edit text, which I thought was so 'lame', (filed a bug on it and
                                                  >
                                                  > was told "thank you for sharing")... and they still create a huge
                                                  >
                                                  > monolith today.
                                                  >
                                                  >
                                                  >
                                                  > -----------------
                                                  >
                                                  >
                                                  >
                                                  > Alexander Shukaev wrote:
                                                  >
                                                  > > Also, it's not that I've planned to develop anything for community. It
                                                  >
                                                  > > was just a fact that I've (probably) pioneered building 64-bit version
                                                  >
                                                  > > of Vim for Windows with support for both Python 2 and Python 3
                                                  >
                                                  > > simultaneously. I guess for others it simply wouldn't compile because
                                                  >
                                                  > > it had to actually be patched in some aspects. I uploaded it primarily
                                                  >
                                                  > > for myself at first. But then it suddenly became popular...
                                                  >
                                                  >
                                                  >
                                                  > Sorry thought of the Marvel Comic superhero line "with great
                                                  >
                                                  > power/talent... comes great responsibilty... *cough*...*sigh*... much
                                                  >
                                                  > too late to be writing this. ;^)

                                                  Hi Linda,

                                                  Found the latest version of vim at http://tuxproject.de/projects/vim/.

                                                  And, only those who have run something like ":%perldo s/dumbness/smartness/gi" in vim will truly understand the beautiful power that vim+perl gives you.

                                                  If people think that Perl is not trendy, please forgive them, for they know not what they speak.

                                                  --
                                                  --
                                                  You received this message from the "vim_use" maillist.
                                                  Do not top-post! Type your reply below the text you are replying to.
                                                  For more information, visit http://www.vim.org/maillist.php

                                                  ---
                                                  You received this message because you are subscribed to the Google Groups "vim_use" group.
                                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                                                  For more options, visit https://groups.google.com/d/optout.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.