> @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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment