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

Re: i write a new vim package/plugin manager like debian's apt

Expand Messages
  • Marc Weber
    ... The community has resources. And the community has wishes. The better the resources are spent on what makes the community happy - the better for everyone
    Message 1 of 12 , Mar 11, 2013
      > @C Campbell
      > The more the merrier:
      The community has resources. And the community has wishes. The better the
      resources are spent on what makes the community happy - the better for everyone
      (IMHO).
      If evrybody keeps solving the same task over and over again -> no progress.
      I know its part of life - but still we as community can try to optimize it - or
      be careless. I want to take care.

      If people want to redo something for joy they may do it. But if they announce
      on the mailinglist I think they should also tell people about why they think their
      tool should be used by users.

      @孔晓泉
      I like you participating.

      > 1.1 some plugin need out of band program to help them, such as ctag,
      > package manager should do something on it
      Can you tell me why you think it should be the "package managers task" to
      provide ctags?

      To prevent "desperation" on user's side 3 lines are enough:

      if !executable('ctags')
      echoe 'well, you don't have ctags. Read the docs to learn where to get it'
      endif

      Let's think the way you do: It should be the task of the package manager to do this:
      What would be required? A solution for:
      windows
      linux (there are many different packaging systems around, at least yum, apt-get, nix)

      For this reason I agree that it would be nice if "vim" could just install a package.
      But in fact I think it would be enough if Vim showed a hint:
      "do apt-get install ctags"

      Maybe we could even write a viml plugin doing exactly that: propose
      installing packages if they don't exist. Then you could use

      call vim_install_helper#SuggestInstall("ctags")

      and it would be the task of the plugin to figure out which is the best
      way to install ctags on the operating system the user is running.

      If there is no implementation it would just say:
      "ctags required, don't know how to suggest installing it. Please patch
      me and contribute".

      I don't want vim to run sudo apt-get .. anyway without being asked. So
      creating a new install hepler plugin seems to be the right thing to do.

      So I think its the task of the plugin to check whether all conditions are met
      so that it can be run. But I disagree that its the task of the plugin or the
      package manager to decide on which packages I want to in install on my computer.

      > 1.2 some plugin need python support or set nocompatible,but unless you
      > read the doc before, you will fall and you don't know why

      Again, I disagree. I don't want a vim plugin manager to
      1) download vim source
      2) configure it
      3) compile and install it somewhere

      which is a better way to handle it?

      fun CheckThenRun(fun, args)
      if !has('python')
      throw "this plugin requires python support"
      endif

      return call(a:fun, args)
      endf

      Then you can use

      map <F2> :call CheckThenRun('your_impl#Fun',[<f-args>])

      or the like - and user will get a nice message telling him what's wrong.

      > 1.4 auto-tools and interaction of other programs, let bash write
      > package name into your .vimrc is not the good path, at least i don't
      > think so.
      Of course you have to think twice or trice before doing such.
      But why is it necessary ? Which problem is solved by such a bash script?

      2.
      vim-addon-manager: Yes, its about that github page, it was initiated by me.
      Today its maintained by me and ZyX.

      3. apt on vim?

      apt: its you calling
      apt install foo
      apt install bar

      apt writes to a databse "foo and bar are installed"

      How does VAM solve this? Compared to apt Vim tries to be declarative (as much
      as declarative as you can be):

      You add to your .vimrc:

      call make_sure_vam_is_installed_otherwise_checkout_from_git()
      vam#Activate(["foo","bar"])


      Then you don't have to install apt, all you have to do is copy your .vimrc in
      place and make sure you have git.

      Next difference. Let's think about this use case:

      When coding java you want plugin A,B
      when coding viml you want plugin A,C

      but you can't use B and C together.

      With VAM you can activate B or C as needed, eg by using project
      setup viml file sourced by vim-addon-local-vimrc.

      For this reason I think that I'm more likely to run into trouble using apt like
      system. I don't want to go back to apt, cause I know and I'm used to the same
      declarative way nixos manages linux packgaes - I can't go back.

      @Ben Fritz:

      > All the OP would have needed to do to figure out that his problem had
      > already been solved, is to visit Google or Bing or
      > whatever and type "vim plugin manager" in the search box.
      Sorry, I personally believe in the community being able to do a better job than
      google does. Google never forgets - but a guide about how to use vim should
      forget some ideas or mark them as outdated.

      @Jon Cairns
      > Is it a problem ? coding is fun?
      If 孔晓泉 was coding it for fun, you're right. At this point I'd be interested
      in whether he has more ideas about what could be coded using his resources - features /
      plugins/ software which does not exist yet.

      I don't want to prevent people from having joy. But I want to ask them whether they
      want to use existing solutions first, then spend their time on new
      things (which are also joyful).

      > If the OP had said that he wrote it because all other package managers sucked
      > then I'd have a problem with that, but it sou
      > like he's doing it for fun and seeing where it's going.
      He didn't use the word "suck", but he said he wants new features which the
      plugin managers he had looked at don't have yet.

      > I do think you have a valid point, but I think that the greatest danger here
      > is quenching people in the open source community
      > from doing what we do.
      Live is short - too short to do something twice for the sake of doing it.
      I personally was doing all the work because I was missing features. And I spent
      a *lot* of time. I wished I could just have done my real job instead.
      Your thinking may be different - and I accept it. So I encourage you to stop me
      when thinking I'm preventing people from having joy within the vim community.
      So please keep reading and commenting on the mailinglist.

      --
      --
      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/groups/opt_out.
    • 孔晓泉
      hello @Marc Weber: Your description made¡¡me see your s deep vimscript foundation.And observation of things nuanced and you and XyZ s VAM is more power than
      Message 2 of 12 , Mar 12, 2013
        hello @Marc Weber:
        Your description made me see your's deep vimscript foundation.And
        observation of things nuanced
        and you and XyZ 's VAM is more power than i think
        you really give some point and make me improved
        but i think you take some mistakes on me and my ideal on vimapt.
        >> 1.1 some plugin need out of band program to help them, such as ctag,
        >> package manager should do something on it
        > Can you tell me why you think it should be the "package managers task" to
        > provide ctags?
        sorry , i write here is "do something on it".
        i not say "here i can't find ctags, vimapt come here, fix it for me"
        the package manager:
        1. can install the ctags (auto or ask the user before do it);
        2. can give info to user like "sorry guys, i can't found ctags, make
        sure you install it or in the system path var";
        3. can give suggest to user like "the ctags is 404, you can use sudo
        apt-get install ctags to install ctags".
        above both are the meaning for "do something on it"
        but which one or two or thress is/are the best "do something on it"?
        i don't know.
        but i think your are right at "provide ctags" is hard on so many os
        and maybe some people don't like this.
        so maybe one or more is(are) the best way to "do something on it", it
        depands on implement and user option.
        if the plugin provide the function to check environment is a good choice,
        but if the package manager provide a uniform interface to handle this
        job. it maybe more better.

        >> 1.2 some plugin need python support or set nocompatible,but unless you
        >> read the doc before, you will fall and you don't know why
        here i means some plugin like "The NERD Commenter "
        it had says "Make sure that you have filetype plugins enabled"
        but if you don't read this and you install it, it not work or not work correct
        so package manager "do something on it": give info or suggest or do
        add to some vimrc file
        at least do one thing on it

        >> 1.4 auto-tools and interaction of other programs, let bash write
        >> package name into your .vimrc is not the good path, at least i don't
        >> think so.
        here i means if you install some language maybe called "xxoo"
        the "xxoo" language want install it's helper plugin to vim for help
        you to more quick write "xxoo"
        how it do it? maybe write a line to your .vimrc like this
        "SomePluginManager#install('xxoo-help')"
        i don't think is the good way, may the "xxoo" call a standard command
        once: "InstallPackge('xxoo')" can slove this problem
        i think it's more good in my ideal.

        > 3. apt on vim?
        >
        > apt: its you calling
        > apt install foo
        > apt install bar
        it's the biggest mistake for vimapt
        vimapt is "apt on vim".it means "vimapt use apt the concept imitate,
        imitate apt mechanism"
        not means it's base on apt or other linux package manager software.

        2013/3/11 Marc Weber <marco-oweber@...>:
        >> @C Campbell
        >> The more the merrier:
        > The community has resources. And the community has wishes. The better the
        > resources are spent on what makes the community happy - the better for everyone
        > (IMHO).
        > If evrybody keeps solving the same task over and over again -> no progress.
        > I know its part of life - but still we as community can try to optimize it - or
        > be careless. I want to take care.
        >
        > If people want to redo something for joy they may do it. But if they announce
        > on the mailinglist I think they should also tell people about why they think their
        > tool should be used by users.
        >
        > @孔晓泉
        > I like you participating.
        >
        >> 1.1 some plugin need out of band program to help them, such as ctag,
        >> package manager should do something on it
        > Can you tell me why you think it should be the "package managers task" to
        > provide ctags?
        >
        > To prevent "desperation" on user's side 3 lines are enough:
        >
        > if !executable('ctags')
        > echoe 'well, you don't have ctags. Read the docs to learn where to get it'
        > endif
        >
        > Let's think the way you do: It should be the task of the package manager to do this:
        > What would be required? A solution for:
        > windows
        > linux (there are many different packaging systems around, at least yum, apt-get, nix)
        >
        > For this reason I agree that it would be nice if "vim" could just install a package.
        > But in fact I think it would be enough if Vim showed a hint:
        > "do apt-get install ctags"
        >
        > Maybe we could even write a viml plugin doing exactly that: propose
        > installing packages if they don't exist. Then you could use
        >
        > call vim_install_helper#SuggestInstall("ctags")
        >
        > and it would be the task of the plugin to figure out which is the best
        > way to install ctags on the operating system the user is running.
        >
        > If there is no implementation it would just say:
        > "ctags required, don't know how to suggest installing it. Please patch
        > me and contribute".
        >
        > I don't want vim to run sudo apt-get .. anyway without being asked. So
        > creating a new install hepler plugin seems to be the right thing to do.
        >
        > So I think its the task of the plugin to check whether all conditions are met
        > so that it can be run. But I disagree that its the task of the plugin or the
        > package manager to decide on which packages I want to in install on my computer.
        >
        >> 1.2 some plugin need python support or set nocompatible,but unless you
        >> read the doc before, you will fall and you don't know why
        >
        > Again, I disagree. I don't want a vim plugin manager to
        > 1) download vim source
        > 2) configure it
        > 3) compile and install it somewhere
        >
        > which is a better way to handle it?
        >
        > fun CheckThenRun(fun, args)
        > if !has('python')
        > throw "this plugin requires python support"
        > endif
        >
        > return call(a:fun, args)
        > endf
        >
        > Then you can use
        >
        > map <F2> :call CheckThenRun('your_impl#Fun',[<f-args>])
        >
        > or the like - and user will get a nice message telling him what's wrong.
        >
        >> 1.4 auto-tools and interaction of other programs, let bash write
        >> package name into your .vimrc is not the good path, at least i don't
        >> think so.
        > Of course you have to think twice or trice before doing such.
        > But why is it necessary ? Which problem is solved by such a bash script?
        >
        > 2.
        > vim-addon-manager: Yes, its about that github page, it was initiated by me.
        > Today its maintained by me and ZyX.
        >
        > 3. apt on vim?
        >
        > apt: its you calling
        > apt install foo
        > apt install bar
        >
        > apt writes to a databse "foo and bar are installed"
        >
        > How does VAM solve this? Compared to apt Vim tries to be declarative (as much
        > as declarative as you can be):
        >
        > You add to your .vimrc:
        >
        > call make_sure_vam_is_installed_otherwise_checkout_from_git()
        > vam#Activate(["foo","bar"])
        >
        >
        > Then you don't have to install apt, all you have to do is copy your .vimrc in
        > place and make sure you have git.
        >
        > Next difference. Let's think about this use case:
        >
        > When coding java you want plugin A,B
        > when coding viml you want plugin A,C
        >
        > but you can't use B and C together.
        >
        > With VAM you can activate B or C as needed, eg by using project
        > setup viml file sourced by vim-addon-local-vimrc.
        >
        > For this reason I think that I'm more likely to run into trouble using apt like
        > system. I don't want to go back to apt, cause I know and I'm used to the same
        > declarative way nixos manages linux packgaes - I can't go back.
        >
        > @Ben Fritz:
        >
        >> All the OP would have needed to do to figure out that his problem had
        >> already been solved, is to visit Google or Bing or
        >> whatever and type "vim plugin manager" in the search box.
        > Sorry, I personally believe in the community being able to do a better job than
        > google does. Google never forgets - but a guide about how to use vim should
        > forget some ideas or mark them as outdated.
        >
        > @Jon Cairns
        >> Is it a problem ? coding is fun?
        > If 孔晓泉 was coding it for fun, you're right. At this point I'd be interested
        > in whether he has more ideas about what could be coded using his resources - features /
        > plugins/ software which does not exist yet.
        >
        > I don't want to prevent people from having joy. But I want to ask them whether they
        > want to use existing solutions first, then spend their time on new
        > things (which are also joyful).
        >
        >> If the OP had said that he wrote it because all other package managers sucked
        >> then I'd have a problem with that, but it sou
        >> like he's doing it for fun and seeing where it's going.
        > He didn't use the word "suck", but he said he wants new features which the
        > plugin managers he had looked at don't have yet.
        >
        >> I do think you have a valid point, but I think that the greatest danger here
        >> is quenching people in the open source community
        >> from doing what we do.
        > Live is short - too short to do something twice for the sake of doing it.
        > I personally was doing all the work because I was missing features. And I spent
        > a *lot* of time. I wished I could just have done my real job instead.
        > Your thinking may be different - and I accept it. So I encourage you to stop me
        > when thinking I'm preventing people from having joy within the vim community.
        > So please keep reading and commenting on the mailinglist.
        >
        > --
        > --
        > 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/groups/opt_out.
        >
        >

        --
        --
        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/groups/opt_out.
      • Marc Weber
        ... If it was a plugin - all package managers could be used .. ... You re right. But almost all .vimrc samples contain it. And this is hard to avoid without
        Message 3 of 12 , Mar 12, 2013
          > but if the package manager provide a uniform interface to handle this
          > job. it maybe more better.
          If it was a plugin - all package managers could be used ..

          > >> 1.2 some plugin need python support or set nocompatible,but unless
          > >> you
          > >> read the doc before, you will fall and you don't know why
          You're right. But almost all .vimrc samples contain it. And this is hard
          to avoid without breaking backward compatibility.
          I'd vote for making "nocompatible" default instantly.

          For nocomp you can check :echo &compatible
          For filetype I don't know exactly - maybe somebody else know.

          I personally struggeled with closing Vim coming from a Windows world
          years ago, - I had trouble understand the help screen which says:

          type :q<Enter> to exit

          Because it didn't come to my mind that the : belongs to the keys to be
          typed.
          I think its more important to tell people about where to get help
          (mailinglist, irc, ...) because this kind of problem is solved fast.

          > [.. many lines you didn't reply to ..]
          @孔晓泉: Consider removing email text you're not replying to.

          Meanwhile I've also read your blog post:
          http://www.howlanderson.net/?cat=33

          I find this interesting:

          quote:
          The concept of the warehouse Provide similar linux distro warehouses
          similar standardized the remote packet warehouse, provide carefully
          check the package through a rigorous screening provides official
          assurance (TODO: due to staffing and funding issues, is preparing for
          the official repository for vim plugin)

          especially:
          rigorous screening provides official assurance

          Do you think somebody will provide the man power to review all packages
          available (or let's say most packages being used?)

          Eventually vim-scripts.org could be called such a warehouse, but without
          screening.

          If you want to collaborate with the VAM team on some topics keep in
          touch.

          Yours
          Marc Weber

          --
          --
          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/groups/opt_out.
        • Marcin Szamotulski
          ... I think this blog post nicely illustrates why we need more cooperation on vim.org: http://delvarworld.github.com/blog/2013/03/16/just-use-sublime-text/
          Message 4 of 12 , Mar 22, 2013
            On 13:47 Tue 12 Mar , Marc Weber wrote:
            > > but if the package manager provide a uniform interface to handle this
            > > job. it maybe more better.
            > If it was a plugin - all package managers could be used ..
            >
            > > >> 1.2 some plugin need python support or set nocompatible,but unless
            > > >> you
            > > >> read the doc before, you will fall and you don't know why
            > You're right. But almost all .vimrc samples contain it. And this is hard
            > to avoid without breaking backward compatibility.
            > I'd vote for making "nocompatible" default instantly.
            >
            > For nocomp you can check :echo &compatible
            > For filetype I don't know exactly - maybe somebody else know.
            >
            > I personally struggeled with closing Vim coming from a Windows world
            > years ago, - I had trouble understand the help screen which says:
            >
            > type :q<Enter> to exit
            >
            > Because it didn't come to my mind that the : belongs to the keys to be
            > typed.
            > I think its more important to tell people about where to get help
            > (mailinglist, irc, ...) because this kind of problem is solved fast.
            >
            > > [.. many lines you didn't reply to ..]
            > @孔晓泉: Consider removing email text you're not replying to.
            >
            > Meanwhile I've also read your blog post:
            > http://www.howlanderson.net/?cat=33
            >
            > I find this interesting:
            >
            > quote:
            > The concept of the warehouse Provide similar linux distro warehouses
            > similar standardized the remote packet warehouse, provide carefully
            > check the package through a rigorous screening provides official
            > assurance (TODO: due to staffing and funding issues, is preparing for
            > the official repository for vim plugin)
            >
            > especially:
            > rigorous screening provides official assurance
            >
            > Do you think somebody will provide the man power to review all packages
            > available (or let's say most packages being used?)
            >
            > Eventually vim-scripts.org could be called such a warehouse, but without
            > screening.
            >
            > If you want to collaborate with the VAM team on some topics keep in
            > touch.
            >
            > Yours
            > Marc Weber
            >
            > --
            > --
            > 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/groups/opt_out.
            >

            I think this blog post nicely illustrates why we need more cooperation
            on vim.org:
            http://delvarworld.github.com/blog/2013/03/16/just-use-sublime-text/

            Best regards,
            Marcin

            --
            --
            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/groups/opt_out.
          Your message has been successfully submitted and would be delivered to recipients shortly.