Might be a need for another plugin here. We might need something to display all the current keybindings and where they are sourced from. I can see where conflicts can arise by chance.
An example that I like is gnu screen, if you remap keybindings in your .screenrc, the help screen reflect the default + your mods.
Not trying to be difficult , but I am missing the point of the organization. I like the idea of a registry of plugins (ala wbonds json file) but I do not see the benefit in having 19 admins (that do not know each other) for these 20 odd repos.
[quote=“slestak989”]Might be a need for another plugin here. We might need something to display all the current keybindings and where they are sourced from. I can see where conflicts can arise by chance.
An example that I like is gnu screen, if you remap keybindings in your .screenrc, the help screen reflect the default + your mods.[/quote]
I could not agree more, I’ve no clue how to pull it off though. There is no automatic way of doing this as far as I know, you could do it manually but somebody has to keep looking for new bindings in that case.
Hey guys,
I have just joined this organization and I do not want to be a Robin Williams in Vietnam but wouldn’t it be nice if we created a repo just for communication? We could ask things via Issues and people have the option to opt out. We could use a mailing group (which I can volunteer to set up on my web server) however Issues on github would be public and have the option to be referred to and flagged as closed or tagged and what not.
I could provide a opt-out-able mailing system too, however since we are already on github we could use the system there and grow the organization into a little knowledge base…
All of this comes from me looking for a way to ask others on github and to be able to attach code on github or even link issues from our plugin repos.
Do you like the idea? It couldn’t hurt right?
I must say I do not dislike this idea. Issues on github are well-conneted with other issues on github by cross-linking other repos and stuff and all in all this seems like the place where “SublimeText” coders can communicate and discuss on problems or something.
I’d also like to mention the #sublimetext IRC channel on freenode where I and several others are helping people with being sublime. You should check there too and you can also discuss small or urgent things there.
I’m new to github, python and sublime plugins, so this may be a silly question, buuutt: if I switch my plugin over to this sublimetext packaged github, is it no longer mine? What all am I transferring over? What happens to all my existing issues for the plugin? who can edit my repository after the switch?
I wouldn’t bother moving over - the org was created in the pre-Package Control days, and I’m not sure it has much purpose anymore.
I think we should remove ST2 support from packages that are compatible with ST3, this way more people will really support this project by buying a license. What do you think?
I will not stop supporting ST2 until ST3 has a stable release - except when it’s a real pain but that hasn’t happened so far.
Some time ago, I announced my support for ST2 would only carry to the release of ST3. When ST3 is offical, I will no longer be supporting ST2. Too much work. With that said, I think if I started getting donations to fund the plugins, I would continue supporting them. I’ve considered cutting off ST2 support before ST3 is official because of all the extra work, but I am a nice guy 
.
Edit: I should state that the my plan is to move the ST2 versions to some archive. I don’t plan on just deleting them, but no more bug fixes or enhancements etc.
I went ahead and just removed the ST2 version of most of the packages I maintain, god people confuse versions and mess installations; the same question in 1000 different forms again and again. 
Isn’t that the truth. I envy you a little with just ditching your ST2 branches. I grow tired of the ST2 support…
Doesn’t the PackageControl plugin supply an online repository for all these things? It also has the benefit of installing them for you with simple in-editor commands…
I found that most compatibility issues of ST2 and ST3 are not related to the api, usually are related to python versions. Particular, I don’t understand why ST2 use python 2.6…it would be much easier if it uses 2.7.
Afaik the SublimeText org was before the Package Control days. Of course it doesn’t make too much sense now that PC exists, but it is still useful if you want your package to be in the hands of skilled or dedicated people who know what they are doing (which I assume all members of the org are).
github.com/SublimeText/Open-Include is a good example for that.