Tell VAM how to place github repositories

[gabriellima]

Is there any VAM variable where you tell how you want to keep repositories?

I.e., now VAM save it like this pattern: ./vim-addons/githubUSERPROJECT

I'd like to, as an example, save this repositorie: github:user/my-project

as: ./vim-addons/github--user--my-project

[MarcWeber]

Excerpts from gabriellima's message of Sat Oct 15 07:30:19 +0200 2011:

Is there any VAM variable where you tell how you want to keep repositories?

I.e., now VAM save it like this pattern: ./vim-addons/githubUSERPROJECT

I'd like to, as an example, save this repositorie: github.com/user/my-project

as: ./vim-addons/github--user--my-project

VAM always has been a 20/80 project: 20% of effort yielding 80% of value. For that reason there are some restrictions such as all plugins must be in the same parent directory which is commonly called "vim-addons". For that reason vim-addons/USER/PROJECT won't work without major rewrite. I'd rater keep things simple. Thus without strong reason I'm not going to introduce nested folders for plugins.

Instead of using the shortcut 'github:..' you can always patch the global dictionary containing sources. Have a look at vim-addon-manager-known-repositories (VAM-kr) for details. The dictionary key will be used as plugin name then - thus you can choose. (or do a =string(g:vim_addon_manager.plugin_sources) in a buffer)

However keep in mind that dependencies are referred to by name as well. Thus it may be best to register a plugin at VAM-kr.

We can also make the function "vam#install#RewriteName(name)" more generic eg overwritable. Then you have more control over names.

[gabriellima]

I got what you mean. But I think you understood a little different.

I dont want to save as "vim-addons/USER/PROJECT"

It'll just be: "vim-addons/user-project" (for example)

No nested folders, just rename of it. I.e, instead of "githubmarcwebervim-addon-manager", it will be "github--marcweber--vim-addon-manager"

But I'll have a look at VAM-kr, because I think that there will be the place to do what I want (as I think you said that).

Thanks.

[ZyX-I]

I guess @gabriellima found a solution in those two weeks.

[gabriellima]

No no, I didn't. Looked at it, but could not patch the way folders are 'named'. However, I'm not paying attention in this specific feature right now, so thanks anyway

[ZyX-I]

@gabriellima Name of the folder = name of the plugin = what you pass to ActivateAddons. You may not do anything to VAM-kr, just add line like

let g:vim_addon_manager.plugin_sources[{new_name}]=g:vim_addon_manager.plugin_sources[{old_name}]

after call to vam#ActivateAddons, use :ActivateAddons old_name to install plugin, rename folder VAM has added and write new name in vam#ActivateAddons call.

[gabriellima]

Ok, now I understood. It's that I thought there would a place to do something like:

Instead of save plugin 'github:scrooloose/nerdcommenter'

as this folder name: githubscrooloosenerdcommenter save with this folder name: github-scrooloose-nerdcommenter

Now I know I can reproduce your steps to do this, but as I have many github plugins linked on my autoload/....vim I thought it'd be good to have some setting like that so that VAM would do this for all github plugins now and in future ... :)

Thanks to answer.

[MarcWeber]

Excerpts from gabriellima's message of Tue Nov 01 19:30:36 +0100 2011:

as this folder name: githubscrooloosenerdcommenter save with this folder name: github-scrooloose-nerdcommenter So you suggest just adding '-' ?

First I'm glad that the feature is actually used :)

Now I know I can reproduce your steps to do this, but as I have many github plugins linked on my autoload/....vim I thought it'd be good to have some setting like that so that VAM would do this for all github plugins now and in future ... :) That's the code you're looking for. So you suggest replacing : by - and / by - as well?

vam#PluginDirByName(name)

How should we do it? Add a "human readable" changelog files telling users about user visible changes such as this?

Then I'm fine with breaking current behaviour. Thoughts?

[ZyX-I]

How should we do it? Add a "human readable" changelog files telling users about user visible changes such as this?

Then I'm fine with breaking current behaviour. Thoughts?

I would suggest keep backward compatibility, by adding a function that is to be used to transform plugin name into directory name:

diff -r 926d477b9a68 autoload/vam.vim
--- a/autoload/vam.vim  Wed Oct 26 00:33:44 2011 +0200
+++ b/autoload/vam.vim  Wed Nov 02 23:26:26 2011 +0300
@@ -46,6 +46,7 @@
 let s:c['change_to_unix_ff'] = get(s:c, 'change_to_unix_ff', (g:os=~#'unix'))
 let s:c['do_diff'] = get(s:c, 'do_diff', 1)
 let s:c['dont_source'] = get(s:c, 'dont_source', 0)
+let s:c['dirname_fun'] = get(s:c, 'dirname_fun', 'vam#Dirname')

 " for testing it is necessary to avoid the "Press enter to continue lines"
 " (cygwin?). Thus provide an option making all shell commands silent
@@ -101,8 +102,11 @@

 endf

+fun! vam#Dirname(name)
+  return substitute(a:name, '[\\/:]\+', '', 'g')
+endfun
 fun! vam#PluginDirByName(name)
-  return s:c['plugin_root_dir'].'/'.substitute(a:name,'[\\/:]','','g')
+  return s:c['plugin_root_dir'].'/'.call(s:c.dirname_fun, [a:name], {})
 endf
 fun! vam#PluginRuntimePath(name)
   let info = vam#AddonInfo(a:name)
diff -r 926d477b9a68 doc/vim-addon-manager.txt
--- a/doc/vim-addon-manager.txt Wed Oct 26 00:33:44 2011 +0200
+++ b/doc/vim-addon-manager.txt Wed Nov 02 23:26:26 2011 +0300
@@ -258,6 +258,11 @@
                         "url": "git://github.com/{N}/{Repo}"}
     git:{URL}          {"type": "git", "url": {URL}} (experimental)

+vam#Dirname({name})                                            *vam#Dirname()*
+    Function that strips back and forward slashes and colons from
+    string. It is used to transform name of the plugin into directory name by
+    default (see |vim-addon-manager-dirname_fun|).
+
 ==============================================================================
 4. Options                                         *vim-addon-manager-options*
                                                          *g:vim_addon_manager*
@@ -313,6 +318,9 @@
         Value will be extended with >
             {"99git+github": "vam#install#RewriteName"}
 <       after it is read (see |vam#install#RewriteName()|).
+dirname_fun                                    *vim-addon-manager-dirname_fun*
+        Function name or function reference which is to be used to transform
+        plugin name into directory name. Default is |vam#Dirname()|.

 The following options are used by vim-addon-manager-known-repositories, not by
 VAM itself. So if you set |vim-addon-manager-known| to another value they may

[MarcWeber]

Excerpts from ZyX-I's message of Wed Nov 02 21:27:54 +0100 2011:

I would suggest keep backward compatibility, by adding a function that is to be used to transform plugin name into directory name: Me as well. But I'd also like the code to be as simple and readable as possible. So I'd like to break with history. Also because

• github* is unstable (it can't/should'nt be use as dependency - you should register names instead)
• its not used much
• everything will continue to work.

What about doing the renaming when checking whether a plugin exists on the fly?

Then

• we only have to add 3 to 4 lines.
• everything is the same on all systems
• people will only get a small confirmation message, confirm renaming and that's it.

I'd prefer that solution. I agree much on 'github-' being more readable than 'github'. But I don't think that there will be much more requests to change the name then. And if we can still introduce yet another configurable function. I don't think we need it right now.

Marc Weber

[ZyX-I]

• github* is unstable (it can't/should'nt be use as dependency - you should register names instead)

It is stable as it is documented as if it was stable.

• everything will continue to work.

No. You don't like to run many vim instances having uptime equal to several weeks, do you? You change autoload/ directory location in some other vim and don't update the rtp setting in current one and suddenly see that plugin Foo is not working.

// It is strange evolution of reload feature provided by pluginloader and then frawor: intended for testing, it has passed through the time when it was not used at all and now is serving for keeping vim uptime so that I can stand 1-5 seconds startup caused by very big values of things like updatecount, parts of viminfo, ... + my parinfo plugin.

• everything is the same on all systems

This point is not changed whatever solution you prefer.

• people will only get a small confirmation message, confirm renaming and that's it.

I would call this yet another annoying confirmation message.

Other points:

• It is not aware of multiple vim instances (I have many and I won't be thankful if you rename plugin with autoload/ directory)
• It does not allow nested subdirectories (if I am not mistaking, my solution allows them at a minimal cost)
• It is less customizable
• It is not written yet

[MarcWeber]

Excerpts from ZyX-I's message of Wed Nov 02 22:40:58 +0100 2011:

It is stable as it is documented as if it was stable. You're right. I remember you dropping my docs. So I had to rewrite it. I'm too lazy to look up whether it was lost there. I meant its a hack only.

So what to do? Your patch doesn't add that much bloat. Still we should make the "-" style the default. Your patch is not good enough. the function should return absolute paths, not relative ones. Then you can even reuse plugins from /usr/share/... if you're crazy.

If we do it - then let's us get it right the this time.

Lines 20 to 23 should be merged into your default function.. http://dpaste.com/646303/ (we should drop it in 12 month or so)

Note that line 10 replace :// by a single - found in git://path.. urls.

chit-chatting:

Seriously: Tell me how often you update plugins. You should be using vim-addon-localrc. Having state in a running vim instance you can't reproduce easily is always bad.

If you run :UpdateAddons you should consider restarting vim because updating plugins reloading plugin files is no guaranteed to work.

Vim was never designed to run forever.

Your impression may be different.

I would call this yet another annoying confirmation message. It will happen once only, people would understand. I'm still unlucky about the "removing sources" message -kr shows confusing new users.. People told me they started installing hg. I'm pretty sure they did not hit a plugin requiring it that time. but I'll shut up.

• It is not written yet I never use code because it has been written yet. Good coders don't write code - they delete code.

That's why I'd use /: chars instead of "forward and backward slashes" cause I'm very lazy (when reading and writing)

[ZyX-I]

You're right. I remember you dropping my docs. So I had to rewrite it.

I dropped only note that it can ease setup on new machine (I can find messages where it was discussed and shown that it won't do so).

Your patch is not good enough. the function should return absolute paths, not relative ones.

What for? There is one common component: vim_addon_manager.plugin_root_dir which is a setting. If you change .dirname_fun so, it will make another setting that is applicable only under some condition. If somebody is crazy enough to put plugins into /usr/share and use this function to make them visible, he can always use ../../../../../../usr/share.

It will happen once only, people would understand.

1. Not once: once per plugin that needs rename.
2. Unwanted confirm() already happened when there was a rebranding with s/vim_script_manager/vim_addon_manager and such.
3. You wrote code that is not working: rename() can't be used to rename directories.

[MarcWeber]

Excerpts from ZyX-I's message of Thu Nov 03 05:36:16 +0100 2011:

What for? There is one common component: vim_addon_manager.plugin_root_dir which is a setting. If you change .dirname_fun so, it will make another setting that is applicable only under some condition. If somebody is crazy enough to put plugins into /usr/share and use this function to make them visible, he can always use ../../../../../../usr/share. Its easier to read than '../../../../..'

1. Unwanted confirm() already happened when there was a rebranding with s/vim_script_manager/vim_addon_manager and such. shut up, about confirmation. Proof that many users are using name rewriting often. Then I'll listen. Its not an issue getting 10 confirmation messages once.
2. You wrote code that is not working: rename() can't be used to rename directories. It does work. Its not important enough to discuss such an implementation detail. If you think differently proof me wrong.

[ZyX-I]

Its easier to read than '../../../../..'

It will obviously show that one is wrong putting plugins in /usr/share. In any case one can always set plugin_root_dir to empty with my solution: all he will miss is code that keeps local changes (and this can be worked around as well).

shut up, about confirmation. Proof that many users are using name rewriting often. Then I'll listen. Its not an issue getting 10 confirmation messages once.

10 confirmation messages each time you launch vim :) Unless you fix this 'unimportant implementation detail'.

It does work. Its not important enough to discuss such an implementation detail. If you think differently proof me wrong.

It is not working: without this implementation detail you will have repository recloned, not moved and thus one will loose local changes. And after you will fix this implementation detail, you'll have more code then I do. More, it is strange to have such a big amount of code for a thing that is to be removed.

You are missing a big amount of customizability: 5 lines (excluding doc) (7 if you want to keep do_diff working with nested folders) and you have solution for every user request without replies like «For that reason there are some restrictions such as all plugins must be in the same parent directory which is commonly called "vim-addons".» This is much more major point then annoying confirmations.

[MarcWeber]

Excerpts from ZyX-I's message of Thu Nov 03 15:32:23 +0100 2011:

It will obviously show that one is wrong putting plugins in /usr/share. In any case one can always set plugin_root_dir to empty with my solution: all he will miss is code that keeps local changes (and this can be worked around as well). Did I say put it there? I meant reusing packages which are installed by system commands! Of course a user should not be allowed to write there then.

10 confirmation messages each time you launch vim :) Unless you fix this 'unimportant implementation detail'. 10 may not reflect the average usage count. I expect it to be 1-5 max and not for all users.

It is not working: without this implementation detail you will have repository recloned, not moved and thus one will loose local changes. I still haven't understood the most basic principle of VAM: "Determinism". If you have local changes its your fault. If you have locale changes you care about you should take action and feed upstream or fork and patch sources. This is the only way to reproduce your setup. That's how VAM is meant to be used. Then there is no issue.

And after you will fix this implementation detail, you'll have more code then I do. Yes - but I expect more users to have the same setup which is important when trouble shooting and helping each other.

The point is: github-FOO is more readable than 'githubFOO'. That's why the default should change. And if that changes you require those lines - because if you don't you'll get lot's of questions.

That's why my current vision is: "merge your and my change" with small modifications:

• returning absolute paths
• do the renaming to keep consistent improved naming for the majority of users. If you personally still opt-out: That's your choice.

[ZyX-I]

Did I say put it there? I meant reusing packages which are installed by system commands! Of course a user should not be allowed to write there then.

How? I never saw a single package manager dropping plugins in different directories (heard something about Gobolinux or such, but I am not sure. If I remember correctly even in this case there should be lots of symlinks instead of lots of items in runtimepath). All have a database containing list of files that belong to particular package.

That's why my current vision is: "merge your and my change" with small modifications:

• returning absolute paths
• do the renaming to keep consistent improved naming for the majority of users. If you personally still opt-out: That's your choice.

Agreed. Check out bookmark dirfunc.

// By the way, I must admit that I was wrong saying that rename() does not work on directories. For some reason it failed to rename test directory + help stated it should be used to rename files.

[MarcWeber]

What does vam#Dirname do? You don't know without looking up docs? Then we should rename it to vam#AddonPathByName(plugin_name) and you don't need docs at all.

The option can be named "addon_path_by_name" and everything is fine. No docs are required.

VAM is meant to be minimal yet useful.

Also tell me which is the use case of opting out from "renaming"?

You also forgot to pay attention to my notice. :// should be replaced by a single - rather than --- because git---fooo-bar looks so ugly?

[ZyX-I]

Then we should rename it to vam#AddonPathByName(plugin_name) and you don't need docs at all.

It is false: you still know nothing about what it does exactly (removes symbols and prepends plugin_root_dir).

The option can be named "addon_path_by_name" and everything is fine. No docs are required.

It is also false: where are you going to get information about the fact that it must return absolute path, that it overrides plugin_root_dir and that it even exists? And your name does not mention that it is a function (function reference or function name).

There cannot be code that does not need docs at all and is human-readable. I'd better have shorter name and documentation then large name and no docs.

Also tell me which is the use case of opting out from "renaming"?

You mean ask_for_rename? If one answers no on dialog he definitely does not want it to show again. So it is better to either remove dialog at all replacing it with echom (if you want user to mention this), or make one able to disable it (if you want user to be able to say 'No'). The only possible use-case I can imagine is plugin whose name by accident is identical to old_name.

You also forgot to pay attention to my notice. :// should be replaced by a single - rather than --- because git---fooo-bar looks so ugly?

No. I just thought that arbitrary non-empty sequence of slashes and colons should be replaced with a single dash, not just ://: mention the \+.

[MarcWeber]

Excerpts from ZyX-I's message of Thu Nov 03 19:43:10 +0100 2011:

It is also false: where are you going to get information about the fact that it returns absolute path, that it overrides plugin_root_dir and that it even exists. You read code. Its as much work as looking up docs - and always accurate.

You mean ask_for_rename? If one answers no on dialog he definitely does not want it to show again. People can always press ctrl-c to abort. And they do want to upgrade. Give me one single reason why people may want to say "n" at all. I don't care about cases which never or rarely happen. So what about allowing [O]k only? :)

People can always opt-out and fork VAM and build/use their own plugin manager. And 80% are not going to touch the default. And if they do something is wrong.

dialog at all replacing it with echom (if you want user to mention this), or make one able to disable it (if you want user to be able to say 'No'). The only possible use-case I can imagine is plugin whose name by accident is identical to old_name. Stop thinking about those cases. Tomorrow you may get ill and die. Live is risk always. Same for computers. Its not likely enough to worry about - and if people can set plugin_sources instead of using the shortcut. And if that case is going to happen you're in trouble when doing a fresh install as well - so why care about it? We're not going to support it as default.

No. I just thought that arbitrary non-empty sequence of slashes and colons should be replaced with a single dash, not just ://: mention the \+. sry then :) - well done.

[MarcWeber]

as this folder name: githubscrooloosenerdcommenter save with this folder name: github-scrooloose-nerdcommenter Why do you want this naming scheme?

Do you want plugins known by vim-addon-mananger-known-repositories be stored in github-name-repo as well? [1]

Or was it just you not liking githubNAMEREPO ?

In that case we could drop the githubNAME and only keep the repo name. Then it would be more like all other plugins.

I don't expect collisions to happen often.

Sorry that there are so many questions appearing ..

[1] using the source-name naming policy always would also cause fresh checkouts when sources change. Then people know that a upstream has changed. Maybe that's not that bad at all?

Thinking about I like it. Or should it be REPO-NAME-github instead so that you can use tab completion in shell etc?

[MarcWeber]

Excerpts from ZyX-I's message of Wed Nov 02 22:40:58 +0100 2011:

• It does not allow nested subdirectories (if I am not mistaking, my solution allows them at a minimal cost) UninstallNotLoadedAddons would break. If we allow subdirs we should at least add some comments. I don't think it'll pay of starting to create a database of "installed plugins".

[ZyX-I]

You read code. Its as much work as looking up docs - and always accurate.

I get this information out of memory, then read docs and only then read code. Parsing code to get docs is always slower then parsing docs. And I read code, user should not do that.

People can always press ctrl-c to abort.

And they do want to upgrade.

Give me one single reason why people may want to say "n" at all.

I don't care about cases which never or rarely happen.

I gave you. And another suggestion: replacing confirm with echom. Not confirm with single option: it is the type of dialogs I really hate.

UninstallNotLoadedAddons would break. If we allow subdirs we should at least add some comments. I don't think it'll pay of starting to create a database of "installed plugins".

It won't as it uses vam#PluginDirByName. But it also won't remove directories except the last one. (I mean, if I use custom function to put plugin into ~/.vam/vim-core/frawor and frawor is the only one in ~/.vam/vim-core, vam#install#UninstallAddons will leave empty ~/.vam/vim-core. I can fix this if you want.)

[ZyX-I]

Stop thinking about those cases. Tomorrow you may get ill and die. Live is risk always. Same for computers. Its not likely enough to worry about - and if people can set plugin_sources instead of using the shortcut.

And if that case is going to happen you're in trouble when doing a fresh install as well - so why care about it? We're not going to support it as default.

«The only possible use-case I can imagine». This phrase is constructed so that it is obvious that I don't believe in possibility of the situation I wrote, but you had dialog and I modified this so that dialog makes sense. In your variant dialog was useless: it was not allowing to really say No (+ if I am correct it would be asking to rename any plugin, whether it changed its name or not, that is what isnot# in my code for).

[MarcWeber]

Excerpts from ZyX-I's message of Fri Nov 04 14:24:44 +0100 2011:

You read code. Its as much work as looking up docs - and always accurate.

I get this information out of memory, then read docs and only then read code. Parsing code to get docs is always slower then parsing docs [..] Not if the fun is one line and is documented. If the user does not understand the code the documentation will not be of much use either because he'll never change the setting. Thus in that particular simple case too much docs are bloat.

Give me one single reason why people may want to say "n" at all. I don't see any. Its an upstream change you want to follow. Its not likely to hurt much (unless you use git submodules - and then you're using pathogen anyway ..)

I don't care about cases which never or rarely happen. I gave you. And another suggestion: replacing confirm with echom. Not confirm with single option: it is the type of dialogs I really hate. I don't want to discuss a one time thing in such detail. I don't care. confirm requires attention of user. And when folders are moved the user should know about it.

UninstallNotLoadedAddons would break. If we allow subdirs we should at least add some comments. I don't think it'll pay of starting to create a database of "installed plugins". It won't as it uses vam#PluginDirByName. But how?

let list = filter(split(glob(vam#PluginDirByName('')),"\n"), 'isdirectory(v:val)') That PluginDirByName('') will break!

Its no longer going to catch all folders. Until now everything had to be in the same directory. Thus globbing was fine. VAM does not keep a list of installed plugins by itself. It does globbing instead - Yes it would be trivial to introduce a state file and a list of plugins. But its bloat for that use case. I'd rather not recommend using subdirectories.

I think you've missed such an implementation:

fun DirByName(name) if name =~ '^github' return '~/github/'.a:name[7,] else return '~/vim-addons/'.a:name endif

and that's when the glob implementation will break (will not do too much harm though - but still)

And that's what was requested: put github:* plugin into github/* only. That's why I asked again about the naming of addon paths of standard

I tried contacting you on irc asking about the system_wide setting. I don't understand when / how it should be used.

[ZyX-I]

But how?

let list = filter(split(glob(vam#PluginDirByName('*')),"\n"), 'isdirectory(v:val)')

That PluginDirByName('*') will break!

Ah, you meant completion. It will break, yes.

I tried contacting you on irc asking about the system_wide setting. I don't understand when / how it should be used.

What's up with this? It is only to mark that VAM itself should not be updated + to determine plugin_root_dir.

[ZyX-I]

I tried contacting you on irc asking about the system_wide setting.

Why not on jabber? It is very unlikely that I will mention someone trying to contact me on IRC, especially not using /msg.

[ZyX-I]

I don't want to discuss a one time thing in such detail. I don't care. confirm requires attention of user. And when folders are moved the user should know about it.

:echohl WarningMsg | echom ... | echohl NONE. Did you see apt-get asking similar things?

[MarcWeber]

So system_wide shares vim-addon-manager only keeping local writable bundle directory?

vam.vim:

let s:c['system_wide'] = !filewritable(expand('<sfile>:h:h:h'))
let s:c['plugin_root_dir'] = get(s:c, 'plugin_root_dir', ((s:c['system_wide'])?
            \                                               ('~/vim-addons'):
            \                                               (expand('<sfile>:h:h:h'))))

Let's say VAM has been installed to /usr/share/bundle/vim-addon-manager Let's say you're root. Then eventually you can write? then system_wide is false thus the (expand(':h:h:h')) is chosen. Thus VAM will install to /usr/share/bundle/* ?

Then in which way is this different from root intsalling into ~/root/.vim/vim-addons or such because users will never plugin_root_dir set to /usr/share/... because they never should be allowed to write to it?

:echohl WarningMsg | echom ... | echohl NONE. Did you see apt-get asking similar things? The difference is: Its you running apt-get. But in this case its VAM asking the user without the user having asked VAM to do something. This just happens after updating VAM. That's why I want a confirm not a echohl.

Anyway: Time to summarize:

I prefer github-MarcWeber-vam over githubMarcWebervam for readability. That's why I agree on changing the default naming policy.

While changing this we can also allow using sub directories - but this would break uninstalling addons using the command.

Because this all is not worth the time we're spending I doubt that many people are going to set custom directory names- that's why I think we don't need perfect documentation and it would be good enough to ask users to read code. The docs should be as minimal as possible as well to make it more likely that users find the section they are looking for providing value to them. Changing naming policy does not (that much) IMHO.

gabriellima stopped participating for now. However his/her last reply took many days - so there may be follow ups.

And I don't want to continue spending much time on this because there is not that much value to gain by doing so except readability of the name.

[ZyX-I]

then system_wide is false thus the (expand(':h:h:h')) is chosen.

Thus VAM will install to /usr/share/bundle/* ?

Yes. Use explicit setting of plugin_root_dir or don't work under root.

Then in which way is this different from root intsalling into ~/root/.vim/vim-addons or such because users will never plugin_root_dir set to /usr/share/... because they never should be allowed to write to it?

AFAIK sudoedit is using temporary file, so it won't normally happen. It was already discussed earlier.

While changing this we can also allow using sub directories - but this would break uninstalling addons using the command.

It would not. The place you pointed me out is code used for completion. Completion will break, but nothing more.

Because this all is not worth the time we're spending I doubt that many people are going to set custom directory names- that's why I think we don't need perfect documentation and it would be good enough to ask users to read code. The docs should be as minimal as possible as well to make it more likely that users find the section they are looking for providing value to them. Changing naming policy does not (that much) IMHO.

If vim docs were written using your approach I would never be using vim at all. Docs must cover everything user may need as reading code takes much more time. There are tags, contents, getting started/FAQ and search to make them usable.

And I don't want to continue spending much time on this because there is not that much value to gain by doing so except readability of the name.

So what? You are making dirfunc master with small modification to code around new confirm?

[MarcWeber]

Excerpts from ZyX-I's message of Fri Nov 04 16:58:27 +0100 2011:

AFAIK sudoedit is using temporary file, so it won't normally happen. It was already discussed earlier. So what is this all about? You're telling me that a option is much more complicated so that you have to add several lines of documentation just to allow using system VAM but per user -kr and addons? Can't the same be done by:

set rtp+=/usr/share/vim-addon-manager let g:vim_addon_manager.plugin_root=$HOME.'/.vim/vim-addons'

Is it really worth keeping that option? Probably you don't even need the rtp+= step?

I still don't get it. Is it meant that the super user can install plugins using vam system-wide? Then users have to opt-out if they want additional plugins (very likely) - because they should not be allowed to write to a shared place.

Then I'd like to simplify and cleanup - because we then can drop one option and simplify docs and remove 3 lines of comments which are hand to understand.

So make me understand why this option exists and what should/does happen if you use VAM as root installing plugins.

It would not. The place you pointed me out is code used for completion. Completion will break, but nothing more. Right. Still worth adding a comment about it.

If vim docs were written using your approach I would never be using vim at all. Docs must cover everything user may need as reading code takes much more time. There are tags, contents, getting started/FAQ and search to make them usable. Well there is a difference: Vim is written in C. You don't have code available and C is ugly to read compared to a one line VimL function. I mean its enough to mention that the option exists. And that's it.

I didn't talk about all docs. I didn't ask for removal. I just ask for removal of self explanatory things because they are likely to break and easy to find.

So what? You are making dirfunc master with small modification to code around new confirm? While simplifying docs I stumbled upon the system_wide option I didn't get. So either docs are missing or it doesn't make sense to me.

[ZyX-I]

So what is this all about? You're telling me that a option is much more complicated so that you have to add several lines of documentation just to allow using system VAM but per user -kr and addons? Can't the same be done by:

It was added because you have

call vam#ActivateAddons(['vim-addon-manager'])

. It the only purpose of this setting: don't make vim-addon-manager activated and updated because it is the job of system package manager (cave in my case). Not system-wide installation by root: it is the job of cave.

Well there is a difference: Vim is written in C. You don't have code available and C is ugly to read compared to a one line VimL function. I mean its enough to mention that the option exists. And that's it.

I didn't talk about all docs. I didn't ask for removal. I just ask for removal of self explanatory things because they are likely to break and easy to find.

Agreed. See last commit.

[MarcWeber]

Excerpts from ZyX-I's message of Fri Nov 04 17:43:28 +0100 2011:

So what is this all about? You're telling me that a option is much more complicated so that you have to add several lines of documentation just to allow using system VAM but per user -kr and addons? Can't the same be done by:

It was added because you have

call vam#ActivateAddons(['vim-addon-manager'])

Why do we have this? Is it because some plugins depend on 'vim-addon-manager'?

Then its a use case for the new feature:

fun CustomAddonPath(addon) if a:addon == "vim-addon-manager" return "/usr/share/vim-addon-manager" else return DefaultIpml(a:addon) endif endf

and everything is fine? (That's why I vote for absolute paths..) Then it will not be checked out. About updating: We should check for write permissions in the update function and show a warning if VAM is not allowed to update a plugin?

is the setting then still necessary?

That's what I was talking about when saying "you ca use system package path instead".

We can even add this as a hack as default: use to get VAM path and return that within that function.

Then VAM only depends on a rtp setting and will never be checked out to a different location. Does this make sense?

If this works then we'll have improved a lot.

[gabriellima]

Hello. Sorry I could not participate on last days.

Replying to MarcWeber

as this folder name: githubscrooloosenerdcommenter save with this folder name: github-scrooloose-nerdcommenter Why do you want this naming scheme? ...... Or was it just you not liking githubNAMEREPO ?

I wanted this naming scheme because I thought more readable.

But, if this feature would cause so much trouble/problem/code as I see in this thread, than I'm fine with default name.

It was just to contribute with what I think about this name.

Thank you all anyway, about talking so advanced about it.

[ZyX-I]

Why do we have this? Is it because some plugins depend on 'vim-addon-manager'?

No, it is because in other case vim-addon-manager won't get updated.

Then its a use case for the new feature:

fun CustomAddonPath(addon)
  if a:addon == "vim-addon-manager"
    return "/usr/share/vim-addon-manager"
  else
    return DefaultIpml(a:addon)
  endif
endf

Stop talking about something put into /usr/share. The default location of vim plugins other then core ones is /usr/share/vim/vimfiles, all of them. This should not be activated for the second time and I can't say what will happen if you resource everything you find there. What is definitely bad is if something defined in /usr/share/vim/vimfiles is overriden in ~/.vim/after.

is the setting then still necessary?

Yes, of course.

Then it will not be checked out. About updating: We should check for write permissions in the update function and show a warning if VAM is not allowed to update a plugin?

It makes sense, but not in this case.

We can even add this as a hack as default: use to get VAM path and return that within that function.

And this does not make sense for me: it will return /usr/share/vim/vimfiles, and then ActivateAddons will activate it...

[ZyX-I]

But, if this feature would cause so much trouble/problem/code as I see in this thread, than I'm fine with default name.

It is already written and as far as I see we managed to come for agreement (at least, last comment was only about system_wide).

[ZyX-I]

By the way, completion malfunction for custom dirname_fun can be fixed if in place of a glob it will do the following:

1. Activate VAM-kr.
2. filter(map(keys(s:c.plugin_sources), 'vam#PluginDirByName(v:val)'), 'isdirectory(v:val)').

At this point there are not much changes, but I have not tested perfomance of this code, especially isdirectory() called 4 thousand times.

[gabriellima]

Nice! So, it's implemented in dirfunc branch?

If so, how should I move my paths to new pattern? I should change my autoload/...vim for that?

Thanks.

[ZyX-I]

Nice! So, it's implemented in dirfunc branch?

If so, how should I move my paths to new pattern? I should change my autoload/...vim for that?

If I understood your request right, you should only update (better if you wait until it appear in master). In this branch you can also make your own dirname_fun with different scheme including vim-addons/USER/PROJECT.

[gabriellima]

Nice to hear that! Thank you! As I'm not a PRO in VimL, I'll wait until this feature come to master branch.

Thank you all for this.

[ZyX-I]

Hm, I now see isdirectory() in

if !s:c['system_wide'] && isdirectory(vam#PluginDirByName('vim-addon-manager'))

. Don't remember when this condition was added, but I guess in this case system_wide can be removed from here and serve only for determining plugin_root_dir.