Disable automatic renaming

[ZyX_I]

Bringing up name issue again.

Suggestion: Plugin name should change if and only if author had renamed it.

Suggestion: First plugin with specific name should have its name unchanged. Second plugin trying to claim the same name should get %NR suffix to it. Utility from #82 should forbid posting such plugins.

Suggestion: When plugin got renamed old name will become an alias for the new name except for the case when renaming happened in three days. Plugin managers should give a warning when trying to install or update renamed plugins using old names.

Suggestion: Name that was once registered must not be reclaimable by other plugins except for the case when plugin with such name was renamed or removed in three days.

Alternative suggestion: removing a plugin frees its name and all aliases to it except for names or aliases that are referenced in any dependencies list.

Plugin manager solution where you cannot write dependency list once is not much helpful. With VAM I cannot just write "dependencies": {"frawor": {}} and expect it to work tomorrow: somebody may posted a fork to www.vim.org meaning that my dependency name is now frawor%3631 and not frawor.

[ZyX_I]

@Shougo @MarcWeber Ping.

[marco-oweber]

If you think its important I don't mind you changing this all - however we should also try to keep things simple. Thus if it happens once or twice least effort might be fix dependencies. As alternative we could try to prevent www.vim.org from allowing assigning the same name a second time .. ?

[ZyX_I]

@MarcWeber You are completely not understanding where effort is lost. Most effort is lost on tracking this situation. I.e. if there is a possibility of this you must be aware of it and somehow check whether your dependencies (of all your plugins) are up-to-date. Rebranding of an existing plugins happens less often, but we have at least 32 plugins that got renamed to plugin%SNR (checked using %s/%\(\d\+\)",\(\n\s*"[^"]*\1"\)\@!//n on script-id-to-name-log.json) and 344 cases when plugin%SNR replaced some other name (checked using %s/%\(\d\+\)",//n).

Preventing www.vim.org from allowing assigning the same name twice (case insensitive) would be handy, but what are you going to do with existing duplicates? There is still a possibility that they get renamed thus removing %SNR part from both plugins affected.

[marco-oweber]

Effort is lost in many ways (see NeoPlugin duplication which is only one example). What to do with existing duplicate names ? keep as is - don't break.

[Thomas Wickham]

I am sorry to introduce this slightly off-topic debate, but why using unique names at all ?

Vim-scripts are replicated on github, most importants plugins are on github, there is a builtin syntax for github. I don't suggest to change the way VAM works, I just don't understand why you consider this feature so important, bringing you all this hassle, when something already works quiet well.

Plus, it's easier to follow and contribute to the plugin if we got the source in the name.

[ZyX_I]

Seems that replying by email did not work directly. Maybe I needed to disable HTML: retrying now. Sorry for late reply, it should not be so late.

[ZyX_I]

It seems that replying by email did not work, thus the late answer:

I am sorry to introduce this slightly off-topic debate, but why using unique names at all ?

Vim-scripts are replicated on github, most importants plugins are on github, there is a builtin syntax for github. I don't suggest to change the way VAM works, I just don't understand why you consider this feature so important, bringing you all this hassle, when something already works quiet well.

Not everything is on github. Vim-scripts is only replicating what is posted to www.vim.org and that is not what we want. And vim-scripts is also using unique names.

We need names to refer to plugins. We need unique names to refer to a specific plugin. We need names and not URLs because they are far easier to remember and type. We must not stick with github because git is not perfect, neither is github. We must not stick with github also because it is not the only resource used for developing.

Also you are completely mistaking when you say that this works quiet well. Because you should say this works quiet well for you. Some of the plugins I use are developed on Google Code. My plugins are on sourceforge (only a few of the oldest ones) and bitbucket.

I do not see much point in bringing github such an advantage, especially given that this project aims at providing database which should become official and definitely widely used. Are you paid by github? If you are not please do not say that somebody should support only one of the alternatives: you are asking to throw away one of our advantages for nothing: we are not paid by github for supporting only them.

Plus, it's easier to follow and contribute to the plugin if we got the source in the name.

No. :AddonsInfo is there for determining what you need and usually you prefer to do less typing to always seeing some URL even in cases like when all you need is to instruct your mate how to install the plugin.

[ZyX_I]

If I am not correct you will see only this part of the message.

If I am correct this part will also be seen: trying to resend with some parts of quoted text stripped out.

[ZyX_I]

Does it just strip all the useful information from the quotes? The

If I am correct this part will also be seen: trying to resend with some parts of quoted text stripped out.

part was supposed to follow the same text as was quoted first in the previous message.

[Thomas Wickham]

@ZyX_I thanks for your long, detailed answer. 2 days is really not a big deal.

First of all, I do not work for github or anyone. If I worked for anything, that would be for Vim and its community. Please don't pollute the debate with creepy questions like these. I do not want to troll or spending freely your time writing answers like that. Your time is more precious than that, and if my question is badly asked, just say so.

I was asking you so because VAM is said to do 80% of the work done, and maintaining this DB of names only for the pleasure of the eyes seems to me as the other 20% part of the work (where dependencies and conflicts are clearly in the 80% part).

Maybe there another Rationale behind ? And maybe we can improve this workflow or simplify things ?

Also you are completely mistaking when you say that this works quiet well. Because you should say this works quiet well for you. Some of the plugins I use are developed on Google Code. My plugins are on sourceforge (only a few of the oldest ones) and bitbucket.

Please excuse me if I implied that VAM should only support github. That was not what I meant.

Yes, all my 20 addons are hosted on github and git is by far my favorite CVS. And I think that also the case for 80% of the vim users (when they use a CVS or addons at all).

That's why I suggested to put github as a first-class citizen (as do Vundle&co btw), because it's more comfortable and I don't really care if some of my plugins are named vim:something%1067 for vim.org addons or gcode:awesome-addon or codeplex:whatever.

Moreover, "<source>:(<owner>/)?<reference>" seems more like a name than an URL to me, and has the advantage to be unique, don't you think ?

Put it in another way, I still do not understand the hassle of maintaining this DB and the community effort you are willing to spend on the long term, considering that addons are such a moving target.

Maybe my question was bad, so here is a new one: what is the rationale behind this DB ? Why do you think vim-pi need it ?

Rather than naming conventions, I would suggest to spend the community effort in an addon discovery and recommendation system (something I was working on and brought me there, I will communicate as soon as my first prototype is ready).

No. :AddonsInfo is there for determining what you need and usually you prefer to do less typing to always seeing some URL even in cases like when all you need is to instruct your mate how to install the plugin.

Maybe typing this vim command works quiet well for you, but I prefer by far reading a declarative file (my .vimrc or whatever) or going to a nice online DB than having to type commands to know this information.

When preferences come in place, there's no more gold rules, isn't it ?

[ZyX_I]

Apparently adding bangs did not work: ref https://bitbucket.org/site/master/issue/8817/reply-by-email-in-issue-tracker-is-pretty#comment-7917403.

! ZyX_I thanks for your long, detailed answer. 2 days is really not a big deal. First of all, I do not work for github or anyone. If I worked for anything, that would be for Vim and its community. Please don't pollute the debate with creepy questions like these.I do not want to troll or spending freely your time writing answers like that. Your time is more precious than that, and if my question is badly asked, just say so. ! ! I was asking you so because VAM is said to do 80% of the work done, and maintaining this DB of names only for the pleasure of the eyes seems to me as the other 20% part of the work (where dependencies and conflicts are clearly in the 80% part). ! ! Maybe there another Rationale behind ? And maybe we can improve this workflow or simplify things ? !

!Also you are completely mistaking when you say that this works quiet well. Because you should say this works quiet well for you. Some of the plugins I use are developed on Google Code. My plugins are on sourceforge (only a few of the oldest ones) and bitbucket.! ! Please excuse me if I implied that VAM should only support github. That was not what I meant. ! ! Yes, all my 20 addons are hosted on github and git is by far my favorite CVS. And I think that also the case for 80% of the vim users (when they use a CVS or addons at all). ! ! That's why I suggested to put github as a first-class citizen (as do Vundle&co btw), because it's more comfortable and I don't really care if some of my plugins are named vim:something%1067 for vim.org addons or gcode:awesome-addon or codeplex:whatever. ! ! Moreover, "<source>:(<owner>/)?<reference>" seems more like a name than an URL to me, and has the advantage to be unique, don't you think ? Put it in another way, I still do not understand the hassle of maintaining this DB and the community effort you are willing to spend on the long term, considering that addons are such a moving target. Maybe my question was bad, so here is a new one: what is the rationale behind this DB ? Why do you think vim-pi need it ? !

If some addon has to be named vim:something%123 and is not in vim-pi then it means that PM using vim-pi has to parse www.vim.org itself to get addon name which is a waste. Vim-pi also links VCS and www.vim.org sources (though for vim-pi it would be probably be better to make both available at once). VAM specifically uses this to update from www.vim.org archives to VCS sources when they become known.

Putting github-only addons to the database does really cost much since this is mostly done by contributors.

! Rather than naming conventions, I would suggest to spend the community effort in an addon discovery and recommendation system (something I was working on and brought me there, I will communicate as soon as my first prototype is ready). !

!No. :AddonsInfo is there for determining what you need and usually you prefer to do less typing to always seeing some URL even in cases like when all you need is to instruct your mate how to install the plugin.! ! Maybe typing this vim command works quiet well for you, but I prefer by far reading a declarative file (my .vimrc or whatever) or going to a nice online DB than having to type commands to know this information. ! ! When preferences come in place, there's no more gold rules, isn't it ? !

There are some generic rules for creating interfaces, but I do not think I am enough proficient to prove anybody's position.