Sublime Forum

Sublime Text Wiki available for documents, screencasts, etc

#1

I’ve updated sublimetextwiki.com so that it can now handle documents.

The first version of the site got blasted by spam, so we lost a lot of stuff, and I moved it to a download site for packages. However, I’ve now updated it so that we can build a repository of markdown documents, using Subversion to handle the content. Here’s the plan.

To contribute to the documents on this site, you’ll need to be a contributor to the package collection. If so, you’ll be largely set.

At the very root of the subversion tree, there is a directory called sublimetextwiki. This is the full content of the site. To edit, you’ll need to;

  • check out the source code from https://sublime-text-community-packages.googlecode.com/svn/sublimetextwiki
  • edit the site.
  • commit changes back.

The site is set up to receive a callback every time the subversion repository, and this callback should refresh the site automatically. It may take 30 seconds or so for changes to appear – more if you’ve committed something large like a screencast, so you may need to be a little patient.

Editing the site is just a matter of knowing the subversion structure. The page content is build in Markdown; all the page content is stored in sublimetextwiki/pagesource, and translated into html pages in sublimetextwiki/pages.

Markdown: daringfireball.net/projects/markdown/

Since markdown doesn’t feature a nice way to link to other markdown documents, I’ve added one. Source content that looks like so:

(\@page-name)

will be considered a link to another maarkdown page, and translated into a link to page-name.html.

I figure this’ll now be a good place for some of the screencasts and similar great stuff that’s being developed.

Steve

sublimetextwiki.com/pages/in … utors.html

0 Likes
#2

Ah, bugger. You may be right.

I suppose I could put up an upload page for big resources, but the thing I like about SVN as the authentication system is that there’s a relatively small, trusted set of folks. Submitting to the site involves exactly the same permissions as uploading new packages.

How’s this for a first pass?

We start using SVN to see if it does cause problems on large commits. If not, we’re good and can continue. If so, we’ll look at putting something else in place.

0 Likes
#3

Nice, but 1024MB?

0 Likes
#4

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?

0 Likes
#5

[quote=“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?[/quote]

Hi. I think I can take the criticism :wink:

  • no, it’s not a wiki, but I owned the domain and I didn’t want to buy SublimeTextDocumentationContributedByDevelopers.com. :wink:
  • 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.
0 Likes
#6

[quote=“sublimator”]
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.[/quote]

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.

0 Likes
#7

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 (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.

0 Likes
#8

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;

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.

0 Likes