I've also got some other subtle touches like when you go from one of the main site pages to a page about a package, I fade out the Package Control logo so it does not compete with the package name.

I'll be posting the website up on GitHub in the next day or two. On the server side it is Bottle.py running on Python 3.3 and using pybars for templating. I used coffeescript with Backbone, D3 and Handlebars as you mentioned, although I did not use the model or collections parts of Backbone. I constructed the beginning of a lightweight framework that feel somewhat declarative in the frontend router so that adding new pages doesn't require any real setup. You write the model code in python to pull data out of the database, then write a handlebars template to display it and then throw in some JS to add interactive elements client-side.

Since I use pybars on the server side and handlebars on the client, I can pre-render the initial page view and then let the client render further screens using just one set of templates. The only downside of using pybars and handlebars is duplicating the helpers.

The other part of the site I am pretty happy with is the search. I use postgres as the database, so I started with the full text searching, but then added some custom functions and triggers to nicely split and weight different parts of the package info. One implementation detail that I think ended up working out decently was weighting results with shorter names higher. This was based on the idea that shorter names mean a larger percentage of the name is a match to the search terms.

and that kinda fucks it up when your shortcuts are: cmd-; cmd-shift-;

I know you can remap in your plugin. Which is great. But this is just a small not to let you (and hopefully other plugin developers) know that this is an issue they should be aware of.

The reason the downloads are truncated to domain is because the URLs tend to be far too long to display in the UI. If you mouse over the domain, you'll see a title attribute with the full URL. This is the same for many elements on the site. Icons, abbreviations and numbers with suffixes all have a title attribute to describe the item in more detail.

Unfortunately I've found the "sync everything" process that you've outlined leads to issues where users end up installing the OS X version of a package on Windows and then wonder why it doesn't work properly.

Additionally, I made pretty liberal use of the title attribute on the site. Most things that are not obvious can be hovered for more information.

https://sublime.wbond.net/installation

ST3 is the default visible tab for the installation instructions.

Many of us have been using ST3 with package control just fine for a while. I really only use it for GoSublime, and it works perfectly on ST3.

No doubt there are perfectly reasonable business explanations for why Sublime doesn't ship with it, but I wouldn't consider upgrading from 2 until 3 was supported.

Anecdote on why the console code is bad and good: by coincidence this afternoon I decided to try ST3, and before using it spent about an hour trying to get Package Control working via the git repo route [1] (Sublime was already inside a local repo, so I had to RTFM git submodule stuff to appease the git_binary error); that went... poorly. I [ab]use Git's functionality, but don't grok it's inner workings well enough to feel like I can use submodules without contaminating the super repo, and eventually gave up when I accidentally came across the page that has the new command [2]. Bam it's working without trouble (after modifying it for the corporate proxy). Like magic it just worked, which was awesome, but silly that something so useful would have any barrier to entry at all.

TL;DR: Package Control is an essential element of the joy of Sublime Text, so it's a little mystifying why it's not just built in.

[1] I can't find the page at the moment. Hopefully I haven't simply hallucinated it somehow. [2] https://sublime.wbond.net/installation

https://sublime.wbond.net/installation#Manual