Sublime Text Wiki available for documents, screencasts, etc

[EJ12N]

Nice, but 1024MB?

This project is currently using approximately 9.3 MB (0.9%) of its 1024 MB repository quota.

[tgkeul]

Good to hear about the upgrade of the package download site.

Please forgive my two vicious remarks:

• sadly, this is no wiki - and I'm too lazy to fool around with subversion. I'll stick to my tiddlywiki at home.
• Why the css template Unnamed(I need sunglasses) while Reinvent will better suite the spirit of sublime?

[SteveCooperOrg]

Good to hear about the upgrade of the package download site.

Please forgive my two vicious remarks:

• sadly, this is no wiki - and I'm too lazy to fool around with subversion. I'll stick to my tiddlywiki at home.
• Why the css template Unnamed(I need sunglasses) while Reinvent will better suite the spirit of sublime?

Hi. I think I can take the criticism

- no, it's not a wiki, but I owned the domain and I didn't want to buy SublimeTextDocumentationContributedByDevelopers.com.
- the CSS template was me grabbing the first one I found and slapping together some build scripts. Luckily, the templates are in the subversion repository so anyone else can have a go at replacing them. I like Reinvent, though, and if I update the site, it'll be to this, or I'll ask Jon for the templates for his site.

[SteveCooperOrg]

Personally, I never really use the xxxxxx.sublime-package files and therefore the wiki/package site.

a) svn is more convenient, especially if you are developing
b) updates, while infrequent, require a restart of Sublime.

That's true -- I don't really use it, either, because I use Subversion too. That makes me wonder if what we'd really benefit from is a simpler way to check for and update all packages direct from the repo, the way Firefox has an addin page and a 'Find Updates' button. The site would not be quite as necessary for package distribution.

I did write a package downloader package, but this was limited because it would conflict with a SVN checkout, so you couldn't use it if you were also developing. Which means that as the package downloader developer, I couldn't use the package downloader... hence the stall. I think that now that we've got the quickpanel, we could make a very nice package downloader, which would find the list of packages and update them directly from subversion. It would require a copy of svn to be installed on the user's system, but my guess is that that's legal. I'll check before I get into anything.

[SteveCooperOrg]

Thereare other approaches to developing documentation and commentary for ST.

Don't Bother

Between the forums and README.txt files in packages, do we need another space? It might be we don't do anything special.

Existing SVN/markdown wiki

The current solution, using Google Subversion for source control, and markdown for writing pages. Limited by Google's 1GB hosting allowance.

Google Wiki

Google code includes a wiki folder (http://code.google.com/p/sublime-text-c ... /#svn/wiki) which appears as a wiki at http://code.google.com/p/sublime-text-c ... ges/w/list

I could just mirror this wiki at sublimetextwiki.com, which would mean that you edit using the site at google code. More wiki-like, but text-only, and so offers no real support for embedded resources like images and screencasts.

Custom Wiki

This is the one that most intrigues me, but would be the most work. The features would be;

- ST as the editor -- no editing in cramped little textareas; the 'edit' link spawns ST, and saving in ST submits the page content back to the site. This gives you syntax highlighting and the power of packages.

- Editing locked to ST owners -- to combat spam, all submissions would have to come from a purchased copy of Sublime Text. This should block all spam but not block any user who had something to contribute.

- local SVN storage. Rather than using Google Code, I'd set up a SVN repo on my web host, and any submission would go through that. Large resources could be uploaded without going into Subversion.

Thoughts?

Those are the ideas I've had so far. I knocked up the current system knowing that it would take me about an hour and would do the job. If we want something better, I'll happily ponder it.

[SteveCooperOrg]

I don't have a lot of time to think about this properly right now, but here's some thoughts -- see if any of them seem

Subversion does allow you to add metadata to folders, so we could use that as a way of tagging a plugin as working with one version or another.

Possibly better would be to copy the way firefox addins work; they have an XML file, I believe, which declares the range of versions they work with.

Now, that might be tricky to handle -- if I upgrade a plugin to 1.2, we still want people to be able to pull out the 1.0 version if it is around. So maybe the thing to do is tie a subversion revision number to a Sublime version; something like adding a text file to the plugin that is structured like this;

Code: Select all

st 1.2: rev 1502
st 1.1: rev 1102
st 1.0: rev  899


The lines read as 'Subversion revision 1502 is the first version that runs onSublime Text 1.2'

Now, if we put that in a named file ('revisionversions.txt') then the build scripts on sublimetextwiki could pull out all three revisions and make three separate sublime-package files.