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

[patch] add sortuniq() function

Expand Messages
  • Cade Foster
    Function sortuniq() for sort and remove duplicates. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the
    Message 1 of 37 , Mar 18, 2014
    • 0 Attachment
      Function sortuniq() for sort and remove duplicates.

      --
      --
      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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/d/optout.
    • Bram Moolenaar
      ... The plugin system can t do much here, it s really up to the plugin author to be testing the changes. We can support alpha and beta versions, but it s
      Message 37 of 37 , Mar 28, 2014
      • 0 Attachment
        Andre Sihera wrote:

        > On 27/03/14 06:42, Bram Moolenaar wrote:
        > > Since many plugins consist of several files, and we would like to check
        > > the dependencies before downloading all the files, the best place for
        > > these dependencies is to have them in a separate manifest file.
        > >
        > > Another advantage is that there would be one central place where plugin
        > > authors upload the newest manifest file. For the moment assume that's
        > > the script storage in vim.org. This also solves the problem of scripts
        > > on vim.org being one file.
        > >
        > > The manifest can specify any place, including git repo's, where to fetch
        > > the files.
        > >
        > > One could also fetch a manifest from elsewhere (e.g. by simply editing
        > > it) and then run the plugin installer/updater. The dependencies can be
        > > in the form of just a plugin ID, to be found in the central repository,
        > > but it could also be the URL of that dependency's manifest file. That
        > > way a plugin author can also publish alpha and beta versions, with
        > > yet unreleased dependencies, before making the fully tested plugin
        > > available at vim.org.
        > >
        > > Using URLs for the location is flexible and easy to debug. Using single
        > > files avoids problems with unpacking archives, the need to first install
        > > tools, etc. I believe all respositories support downloading individual
        > > files. What this does NOT support is further developing the plugin or
        > > merging local changes. Normal users won't need that.
        > >
        >
        > Have you ever had the opportunity of doing ruby programming and having to
        > use "bundle" or some other "gem" manager? What you're proposing is very
        > similar and I would recommend you install ruby, play with it, and get to
        > know the "gem" managers before embarking down this path.
        >
        > Due to the fact that such systems give the impression that it is "easy" for
        > the user to upgrade to the latest version, it engenders a cavalier attitude
        > amongst plugin writers that proper test/release control is unnecessary;
        > they just dump out the latest version without testing because if it contains
        > a bug they can just fix it and dump out yet another version with the fix.
        >
        > Particularly in the workplace, and I speak from personal experience, these
        > kinds of systems do waste more time than they save due to everything
        > grinding
        > to a halt due when one plug-in in a dependency hierarchy breaks, normally
        > because the plug-in author couldn't be bothered to test their code
        > adequately
        > before releasing it. Add to this the usual system integrity problems that
        > accompany network-based systems and we have more headaches in the making.

        The plugin system can't do much here, it's really up to the plugin
        author to be testing the changes. We can support "alpha" and "beta"
        versions, but it's still the author who decides what gets released.

        There are two main reasons for a new version:
        - New features added. In this case it depends on a few users to try
        them out. That means there must be users who really want these new
        features.
        - A problem is reported, the plugin author fixes it and points the bug
        reporter to a new version to verify the problem is fixed. Only after
        confirmation the new version is released.

        Both require being able for a user to point to a specific, unreleased
        version of a plugin. Doing that with a URL to the manifest would work.

        > If you do implement this system, may I strongly suggest that you invest more
        > time in the backup/rollback features than the install/management features?
        > That way when things go wrong we can be sure we can get back to where we
        > want
        > to get back to as quickly and as painlessly as possible.

        Good point, besides being able to try out a new plugin, which means it
        must be easy to remove it again, we should also have an easy way to go
        back to a previous version. And that means to before the last time the
        plugins were updated.

        For a user who knows what he is doing he could perhaps select a specific
        version of a specific plugin, but for most users it would be:
        1. Install various plugins, use them.
        2. Run "update all plugins"
        3. Use the new versions.
        4. If a problem is noticed, do a "go back one step", which means undo
        the last update.

        A multi-level undo is needed, since it can be a few days before you
        notice a problem.

        --
        Engineers understand that their appearance only bothers other people and
        therefore it is not worth optimizing.
        (Scott Adams - The Dilbert principle)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        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

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