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

Re: vim sf page ratings and feedback feature

Expand Messages
  • Marc Weber
    Hi Ben, ... Just think about missing one comment: This plugin is superseded. It has been merged with xy.. use xy instead How much value can this one comment
    Message 1 of 20 , Feb 9, 2010
    • 0 Attachment
      Hi Ben,

      Excerpts from Ben Fritz's message of Tue Feb 09 17:40:15 +0100 2010:
      > plugin out there, [..]

      Just think about missing one comment:

      "This plugin is superseded. It has been merged with xy.. use xy instead"

      How much value can this one comment generate for you?

      Think about the original plugin author either
      a) died
      b) is no longer interested
      c) forgot his password (Yes! There is no way to get back a password. The page tells you so!)

      I agree that we never ever want to delete any version. But I think we
      must have a way to mark such packages as deprecated.

      I've started doing so in vim-addon-manager-known-repositories.
      However not many people are using it at this point in time.

      Why is this that important:
      If you look for scripts you do search www.vim.org first.
      It's much more unlikely that you look for comments on a wiki.

      I dream of:

      get plugin vim-addon-c(pp)-tools and have *all* features I can get doing C(++) development using Vim.
      Same for Ruby, Vim, Perl, Python, C#, etc.

      Because if man power is spread results will suffer. Vim *is* a great
      editor. However to keep everything working we have to join efforts else
      people (including me) will use Eclipse or such as main editor because
      IDE features do matter a lot. I agree that I'm a programmer and that I
      want to see specific features to get my work done faster. But it's
      programmers who can move Vim into the future. And if programmers have to
      spend weeks on setting up Vim they may just use another tool. Vim will
      never die. But it maybe won't have the market share it deserves..

      There are more things I don't understand yet. Python and Ruby are
      supported by Vim. But all interfaces seem to provide only a exec and a
      vimeval function. If you want to execute a simple command such as echoe
      you have to start thinking about quoting strings. Why don't those
      interfaces provide a simple vim_escape function ?
      But that's a different (off) topic..

      Marc Weber

      --
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Bram Moolenaar
      ... The problem with feedback is that spammers will misuse it. We have had this problem with Vim tips before they were moved to the wikimedia site. If we can
      Message 2 of 20 , Feb 9, 2010
      • 0 Attachment
        Marc Weber wrote:

        > Hi Bram & community,
        >
        > There are two things on the Vim sf page which bugged me for years:
        >
        > a)
        > There is no way for users adding comments.
        >
        > So as plugin author you just get feedback like a rating -2/2 but you
        > have no clue why. That's very disappointing.
        > This happened to me recently.
        > http://www.vim.org/scripts/script.php?script_id=2934
        > I think this plugin is great because you don't have to remember dozens
        > of mappings.
        >
        > To keep open source projects active you need positive feedback loops.
        > This doesn't happen for Vim plugins.
        >
        > So consider one case: You have uploaded a bug by accident. One users
        > downloads your plugin. It doesn't work. So he rates the plugin with
        > (-1).
        >
        > You can fix the bug. You rating is still -1. The only thing you can do
        > about it is polluting the page by adding a new plugin-name which is bad.

        The problem with feedback is that spammers will misuse it. We have had
        this problem with Vim tips before they were moved to the wikimedia site.

        If we can put the comments also on the wikimedia site, with a link to
        it, perhaps that would work.

        > b)
        > users can't add comments. So if there is a newer plugin or if
        > something didn't work or if users have additional comments whatsoever
        > they can't put them on the site. The result is that the site isn't as
        > valuable as it could be. Eg have a look php.net. If there is a bug
        > everyone can upload a comment posting his workaround. It's ugly but it
        > works pretty well.
        >
        > Indeed it can be much simpler. Adding one link to a discussion site on
        > the Vim wiki eg http://$VIMWIK/pulgin_plguin_nr would be enough.
        > Zero effort but much value.

        You can already add links, but a generic mechanism would indeed be
        better.

        There, I added a link in the header. Let me know if this will work.

        John Beckett can perhaps set up a template for a scripts wiki page.

        > c) (less important)
        > Plugin information can't be exported. This I and the author of Vimana
        > we both implemented hacks to get a list of plugins to support
        > installing plugins in an easier way.
        >
        > So I'd like to add an interface which returns a big json dict (which
        > can be read by Vim!) telling about all plugins and their latest
        > versions. This will safe some traffic and a lot of CPU power..

        Since there is no specified format, I don't know of a reliable way to do
        this.

        I don't think there is a way to get a list of uploaded files by date.
        Perhaps that's all you need.

        > I know both: PHP and MySQL. I can do all changes. There is one thing I'm
        > unsure about. The Vim database contains information about who donated
        > how much. This is sensible data. I'm not sure whether I should know
        > about those records.
        >
        > So what shall I do to get these features implemented? Ask community on
        > the mailinglist how they think about it?
        >
        > Those changes don't cause much work. But they will generate much value
        > to everyone.

        I'm careful about giving more people access to the site directly. If
        you say what page you would want to change I can send you the php code
        and you can send me a diff.

        --
        hundred-and-one symptoms of being an internet addict:
        211. Your husband leaves you...taking the computer with him and you
        call him crying, and beg him to bring the computer back.

        /// 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
      • Tux
        ... BTW, did you switch SF.net s new no export to North Korea switch? -- You received this message from the vim_dev maillist. For more information, visit
        Message 3 of 20 , Feb 9, 2010
        • 0 Attachment
          Bram Moolenaar schrob am 09.02.2010 21:20:
          > I'm careful about giving more people access to the site directly.
          >

          BTW, did you switch SF.net's new "no export to North Korea" switch?

          --
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
        • John Beckett
          ... Yes, we could request a namespace specifically for discussion of vim.org scripts. However, while the problem with vim.org/scripts is real, I do not want a
          Message 4 of 20 , Feb 9, 2010
          • 0 Attachment
            Ben Fritz wrote:
            > For a while now, we've been resisting having a wiki page for
            > every plugin out there, as such information could easly become
            > overwhelming or get out of date. We want searches on the wiki
            > to show mostly tips about how to use Vim, how to write
            > scripts, etc. We didn't want it to become a place to search
            > for plugins.
            >
            > Perhaps it would be possible, if we create a new namespace for
            > the plugin pages (I think this is possible). Searches would by
            > default not include these pages, but a user could specify that
            > they *wanted* to search the plugin namespace if desired.

            Yes, we could request a namespace specifically for discussion of
            vim.org scripts. However, while the problem with vim.org/scripts
            is real, I do not want a bunch of extra pages dumped on the wiki
            because such pages:
            - overwhelm people looking for basic information
            - become obsolete as once-enthusiastic authors move on
            - have to be maintained by me and Ben Fritz

            If we could start again, vim.org/scripts might be managed
            differently, but I think there is too much history now for any
            realistic collaboration between the scripts site and a wiki
            because we cannot force people to update the information on two
            different sites.

            If it were possible to put the plugins into a reasonably small
            number of categories, then it would be reasonable to have one
            wiki page per category of script. For example, one wiki page
            would list all non-obsolete plugins relating to searching, with
            brief notes on status and usage, and a link to the
            vim.org/scripts page for installation and usage notes.

            I made a page on the wiki to hold various scripts that had
            previously been described in separate tips. I think the format
            is useful to allow readers to quickly scan for interesting
            scripts:
            http://vim.wikia.com/wiki/Vim_scripts

            There was a suggestion that a wiki page would allow users to
            write meaningful comments with useful feedback. Unfortunately,
            I think useful comments would be very rare because people are
            overwhelmed with choice on the Internet, and Vim is now just
            another tool, and the hard-core Vim users are just using Vim,
            having got over the initial wave of evangelism that creates an
            interactive fan base.

            John

            --
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
          • Ingo Karkat
            ... I agree that there should be very few committers to the site; however, in my opinion, freely sharing the (PHP) source code of the site might have
            Message 5 of 20 , Feb 9, 2010
            • 0 Attachment
              On 09-Feb-2010 21:20, Bram Moolenaar wrote:
              > I'm careful about giving more people access to the site directly. If
              > you say what page you would want to change I can send you the php code
              > and you can send me a diff.

              I agree that there should be very few committers to the site; however, in my
              opinion, freely sharing the (PHP) source code of the site might have encouraged
              more people to send you a patch in order to improve the site's functionality.
              As it is, there are these occasional discussions about the site's deficiencies,
              but nobody is able to step up and implement an alternative, because the source
              code is relatively closed.

              So, I would propose putting the vim.org's source code (not the actual user
              database and scripts!) into a (Mercurial?) repository (separate from Vim's
              source code).

              -- regards, ingo

              --
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
            • Bram Moolenaar
              ... This would also make the site vunerable for hackers. I don t know enough PHP to locate possible holes and opening it up won t fix that. I rather not do
              Message 6 of 20 , Feb 10, 2010
              • 0 Attachment
                Ingo Karkat wrote:

                > On 09-Feb-2010 21:20, Bram Moolenaar wrote:
                > > I'm careful about giving more people access to the site directly. If
                > > you say what page you would want to change I can send you the php code
                > > and you can send me a diff.
                >
                > I agree that there should be very few committers to the site; however,
                > in my opinion, freely sharing the (PHP) source code of the site might
                > have encouraged more people to send you a patch in order to improve
                > the site's functionality. As it is, there are these occasional
                > discussions about the site's deficiencies, but nobody is able to step
                > up and implement an alternative, because the source
                > code is relatively closed.
                >
                > So, I would propose putting the vim.org's source code (not the actual
                > user database and scripts!) into a (Mercurial?) repository (separate
                > from Vim's source code).

                This would also make the site vunerable for hackers. I don't know
                enough PHP to locate possible holes and opening it up won't fix that.
                I rather not do this. Having only a few maintainers looking at the code
                is better.

                --
                hundred-and-one symptoms of being an internet addict:
                212. Your Internet group window has more icons than your Accessories window.

                /// 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
              • Tom Sorensen
                ... Really? Security through obscurity? If the site is vulnerable, then I don t believe that having the source hidden is going to significantly deter a hacker.
                Message 7 of 20 , Feb 10, 2010
                • 0 Attachment
                  On Wed, Feb 10, 2010 at 9:47 AM, Bram Moolenaar <Bram@...> wrote:
                  > This would also make the site vunerable for hackers.  I don't know
                  > enough PHP to locate possible holes and opening it up won't fix that.
                  > I rather not do this.  Having only a few maintainers looking at the code
                  > is better.

                  Really? Security through obscurity?

                  If the site is vulnerable, then I don't believe that having the source
                  hidden is going to significantly deter a hacker. It will certainly
                  impede any attempts to fix it though.

                  I love vim and greatly appreciate all of the work you've put into it
                  and the community over the past two decades. But the website really
                  could use some improvement. The wiki has done a lot to fill some of
                  the need (a need we see regularly on the #vim IRC channel), but having
                  tighter integration with the main site would be far better, without
                  overwhelming the wiki. That's not going to happen unless people like
                  Marc can easily and readily provide help where they can.

                  Tom

                  --
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                • Marc Weber
                  We should start a wiki page containing a website wish list. We can put up a summary of changes there. Bram: I m totally fine with sending you diffs. If nobody
                  Message 8 of 20 , Feb 10, 2010
                  • 0 Attachment
                    We should start a wiki page containing a website wish list.
                    We can put up a summary of changes there.

                    Bram: I'm totally fine with sending you diffs.

                    If nobody else does I'll create this wiki page within 24h

                    Marc Weber

                    --
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                  • Marc Weber
                    Done. If you have further suggestions reply to this thread or add them to this wiki page yourself.
                    Message 9 of 20 , Feb 10, 2010
                    • 0 Attachment
                      Done. If you have further suggestions reply to this thread or add them
                      to this wiki page yourself.
                      http://vim.wikia.com/index.php?title=Vim_Homepage_Wishlist&action=edit

                      I also suggested removing the negative rating feature. Maybe its
                      misused. If people don't like a plugin they should add comments telling
                      why.

                      Also have a look at a new idea e) It may or it may not take off.
                      I think there are that many people using vim that this could actually
                      make sense..

                      e) I'd like to see Vim making more progress. Thanks to Bram for having
                      added completion features. However there is more which could be done.
                      What's the problem? Vim is complex. Many configuration options, many
                      guis. So it's hard to test. You need some time getting started. Most
                      people just want to get done their job. So it's hard to get started in
                      Vim development. So what about adding a page to the homepage where
                      everyone can add a feature request and say he'd pay $ x for it. Someone
                      else might join and say he'd pay $ y for it. Then a third person steps
                      up and says: Hey. I'd take the money and implement it (maybe a fraction
                      can be given to Uganda?). Than a Vim developer can have an (probably
                      small ?) income and many people can benefit. Such a feature wish list
                      could look like:

                      feature | description | sum of $ which people are willing
                      | | to spend on developing a feature
                      -------------------------------------------------------------------------------------------------
                      async communication| find a way to talk to external apps. | $100 (3 people)
                      | This will make implementing debuggers |
                      | and the like feasable |
                      -------------------------------------------------------------------------------------------------
                      on the fly | make scripting languages provide |
                      type checking | the error list |
                      -------------------------------------------------------------------------------------------------
                      on :e! don't loose | |
                      history | |

                      Does a simple buildfarm exists which builds Vim in various configuration
                      options doing some sanity checks?

                      Marc Weber

                      --
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                    • Ingo Karkat
                      ... PHP is very common; there are many Vim users with a lot of PHP knowledge out there. The vim.org site isn t very complex; I guess one or two capable
                      Message 10 of 20 , Feb 10, 2010
                      • 0 Attachment
                        On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                        > Ingo Karkat wrote:
                        >> So, I would propose putting the vim.org's source code (not the actual
                        >> user database and scripts!) into a (Mercurial?) repository (separate
                        >> from Vim's source code).
                        >
                        > This would also make the site vunerable for hackers. I don't know
                        > enough PHP to locate possible holes and opening it up won't fix that.
                        > I rather not do this. Having only a few maintainers looking at the code
                        > is better.

                        PHP is very common; there are many Vim users with a lot of PHP knowledge out
                        there. The vim.org site isn't very complex; I guess one or two capable
                        contributors would be able to quickly review and fix any security issues. I
                        certainly would (but I'm afraid my PHP isn't any better than yours), just out of
                        gratitude for Vim and the great community.

                        Leaving aside the whole "security by obscurity" topic, I'd venture that the
                        tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
                        a risk. As you can see from the replies to this thread, the current site is
                        minimal and okay, but there are many ideas for improvements out there. In the
                        past years, many open source projects have really lifted the bar for community
                        sites...

                        -- regards, ingo

                        --
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                      • Marc Weber
                        ... I don t think it s a problem. Bram said he will forward sources to interested people. I just said he won t forward it to everyone. I don t think this is
                        Message 11 of 20 , Feb 11, 2010
                        • 0 Attachment
                          Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:
                          > On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                          > > Ingo Karkat wrote:
                          > >> So, I would propose putting the vim.org's source code (not the actual
                          > >> user database and scripts!) into a (Mercurial?) repository (separate
                          > >> from Vim's source code).
                          > >
                          > > This would also make the site vunerable for hackers. I don't know
                          > > enough PHP to locate possible holes and opening it up won't fix that.
                          > > I rather not do this. Having only a few maintainers looking at the code
                          > > is better.
                          >
                          > PHP is very common; there are many Vim users with a lot of PHP knowledge out
                          > there. The vim.org site isn't very complex; I guess one or two capable
                          > contributors would be able to quickly review and fix any security issues. I
                          > certainly would (but I'm afraid my PHP isn't any better than yours), just out of
                          > gratitude for Vim and the great community.
                          >
                          > Leaving aside the whole "security by obscurity" topic, I'd venture that the
                          > tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
                          > a risk. As you can see from the replies to this thread, the current site is
                          > minimal and okay, but there are many ideas for improvements out there. In the
                          > past years, many open source projects have really lifted the bar for community
                          > sites...

                          I don't think it's a problem. Bram said he will forward sources to
                          interested people. I just said he won't forward it to everyone. I don't
                          think this is limiting us. We have to know how the "new" (?) site should
                          look like. So let's discuss new features or changes rather than the how
                          to do it. Bram replied and he's listening. So I'm sure we'll find a way
                          to achieve the goals. We have to define those.

                          Marc Weber

                          --
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                        • Ben Schmidt
                          ... My PHP is pretty good; MySQL also, though old-fashioned. If I can be of assistance looking over code, or helping with development for a better site, I d be
                          Message 12 of 20 , Feb 11, 2010
                          • 0 Attachment
                            On 12/02/10 3:34 AM, Marc Weber wrote:
                            > Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:
                            >> On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                            >>> Ingo Karkat wrote:
                            >>>> So, I would propose putting the vim.org's source code (not the actual
                            >>>> user database and scripts!) into a (Mercurial?) repository (separate
                            >>>> from Vim's source code).
                            >>>
                            >>> This would also make the site vunerable for hackers. I don't know
                            >>> enough PHP to locate possible holes and opening it up won't fix that.
                            >>> I rather not do this. Having only a few maintainers looking at the code
                            >>> is better.
                            >>
                            >> PHP is very common; there are many Vim users with a lot of PHP
                            >> knowledge out there. The vim.org site isn't very complex; I guess one
                            >> or two capable contributors would be able to quickly review and fix
                            >> any security issues. I certainly would (but I'm afraid my PHP isn't
                            >> any better than yours), just out of gratitude for Vim and the great
                            >> community.

                            My PHP is pretty good; MySQL also, though old-fashioned. If I can be of
                            assistance looking over code, or helping with development for a better
                            site, I'd be more than happy to.

                            I agree with Bram and Marc that having a few interested people looking
                            at the site code rather than making it public is fine. We're a pretty
                            tech-savvy community, but that doesn't mean everybody has time to devote
                            to fixing security holes, particularly not with the sort of notice you
                            get with a hacker attack!

                            Ben.




                            --
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                          • Ben Fritz
                            ... John s been a busy bee and got a new namespace on the wiki for script comments, a policy page for it, and a nifty template for each script page providing a
                            Message 13 of 20 , Feb 13, 2010
                            • 0 Attachment
                              On Feb 10, 12:44 am, "John Beckett" <johnb.beck...@...> wrote:
                              > Yes, we could request a namespace specifically for discussion of
                              > vim.org scripts. However, while the problem with vim.org/scripts
                              > is real, I do not want a bunch of extra pages dumped on the wiki
                              > because such pages:
                              > - overwhelm people looking for basic information
                              > - become obsolete as once-enthusiastic authors move on
                              > - have to be maintained by me and Ben Fritz
                              >

                              John's been a busy bee and got a new namespace on the wiki for script
                              comments, a policy page for it, and a nifty template for each script
                              page providing a disclaimer and brief instructions, along with the
                              script name and a link back to vim.org.

                              Check it out:

                              http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
                              http://vim.wikia.com/wiki/Script:1234

                              Bram, I'm not sure if John emailed you privately, but if you'd change
                              the link to the wiki on vim.org pages from Script-1234 to Script:1234,
                              I think that's all that you need change.

                              Comments are, of course, welcome.

                              --
                              You received this message from the "vim_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                            • Marc Weber
                              ... Looks great. However I d move the Wiki link near the rating. And I d still remove negative ratings. Scripts which are awesome will have a high rating
                              Message 14 of 20 , Feb 13, 2010
                              • 0 Attachment
                                Excerpts from Ben Fritz's message of Sat Feb 13 19:16:42 +0100 2010:
                                >
                                > On Feb 10, 12:44 am, "John Beckett" <johnb.beck...@...> wrote:
                                > > Yes, we could request a namespace specifically for discussion of
                                > > vim.org scripts. However, while the problem with vim.org/scripts
                                > > is real, I do not want a bunch of extra pages dumped on the wiki
                                > > because such pages:
                                > > - overwhelm people looking for basic information
                                > > - become obsolete as once-enthusiastic authors move on
                                > > - have to be maintained by me and Ben Fritz
                                > >
                                >
                                > John's been a busy bee and got a new namespace on the wiki for script
                                > comments, a policy page for it, and a nifty template for each script
                                > page providing a disclaimer and brief instructions, along with the
                                > script name and a link back to vim.org.
                                >
                                > Check it out:
                                >
                                > http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
                                > http://vim.wikia.com/wiki/Script:1234
                                >
                                > Bram, I'm not sure if John emailed you privately, but if you'd change
                                > the link to the wiki on vim.org pages from Script-1234 to Script:1234,
                                > I think that's all that you need change.

                                Looks great. However I'd move the Wiki link near the rating. And I'd
                                still remove negative ratings. Scripts which are awesome will have a
                                high rating anyway and you're interested in them.

                                Is there a way to add the wiki frame to the vim sf script page?
                                If some people don't like it we can add an option to hide it (based on
                                cookies).

                                Marc Weber

                                --
                                You received this message from the "vim_dev" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                              • Tony Mechelynck
                                On 11/02/10 01:23, Marc Weber wrote: [...] ... It s easy to construct one, but only on Unix-like systems, including Unix-like Cygwin and (IIUC) Mac OS X. Not
                                Message 15 of 20 , Apr 4, 2010
                                • 0 Attachment
                                  On 11/02/10 01:23, Marc Weber wrote:
                                  [...]
                                  > Does a simple buildfarm exists which builds Vim in various configuration
                                  > options doing some sanity checks?
                                  >
                                  > Marc Weber
                                  >

                                  It's easy to construct one, but only on Unix-like systems, including
                                  Unix-like Cygwin and (IIUC) Mac OS X. Not on native-Windows AFAIK,
                                  because the configure script doesn't run on that platform. I guess you
                                  (Marc) know the following but I'm spelling it out for anyone interested:

                                  0) Get the source.
                                  1) Make as many "shadow" subdirectories of src/ as you want different
                                  configurations, using "make shadow" with src/Makefile; after each pass,
                                  rename src/shadow (or comment away the Makefile line "SHADOWDIR =
                                  shadow" and define SHADOWDIR differently yourself for each run of "make
                                  shadow").
                                  2) Construct shell include scripts (let's call them
                                  src/$SHADOWDIR/config.sh) similar to the one near the top of my howto
                                  page http://users/.skynet.be/antoine.mechelynck/vim/compunix.htm , one
                                  per configuration with the desired settings.
                                  -- For some particularly "unusual" configurations, you may have to break
                                  the softlink for feature.h and comment or uncomment some of its lines
                                  differently in different shadowdirs.
                                  3) In each shadowdir:
                                  source config.sh
                                  make && make test

                                  Notes:

                                  * Run the above in a different shell for each shadowdir to avoid stray
                                  environment variables carrying over from one run to the next. You may
                                  run them in parallel if you want (and if your machine has the resources
                                  to make it useful).

                                  * config.sh must be sourced, not run, because its purpose is to modify
                                  the environment: it must NOT be run in a subshell.

                                  * "make" runs configure implicitly if auto/config.cache doesn't exist;
                                  if you changed the config.sh or the installed software, use "make
                                  reconfig" instead (or precede "make" by rm -vf auto/config.cache or by
                                  make distclean) to force a configure pass followed by a full compile.

                                  * "make test" is supposed to run a number of post-compile sanity checks
                                  on the newly produced executable. I haven't tried it yet. Pre-compile
                                  sanity checks (on your software environment and configuration settings)
                                  are done by configure.


                                  Best regards,
                                  Tony.
                                  --
                                  TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
                                  ARTHUR: All right! What do you want?
                                  TALL KNIGHT: We want ... a shrubbery!
                                  "Monty Python and the Holy Grail" PYTHON (MONTY)
                                  PICTURES LTD

                                  --
                                  You received this message from the "vim_dev" 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

                                  To unsubscribe, reply using "remove me" as the subject.
                                Your message has been successfully submitted and would be delivered to recipients shortly.