Feature Request: User-build addins

[SteveCooperOrg]

Consider three apps that benefit massively from a plugin system;

• Firefox
• Eclipse
• emacs

Each of them has 'come to power' because power users can hack the program to work as they really like. The basic system just provides hooks and programmers can extend the app to work well in particular, specialised ways.

Sublime Text already has python and macro extensions, but right now there is little documentation and no way, AFAIK, to deploy new addins -- new command sets, themes, macros, language definitions, etc.

Possibly, if good addins appear, and they become popular, the features could be woven back into Sublime. It's a mechanism for users to experiment without overloading Jon with feature requests, and seeing what sticks.

Key features would be;

• package up all necessary files into a single package (like XUL, JAR)
• web repository for new packages
• Tools | Addins menu item for managing new addins.

A massive feature, I know, but I thought I'd see if others are interested in developing for ST.

Here's a link to the most popular firefox plugins, as background.

addons.mozilla.org/en-US/firefo ... rt:popular

[jps]

Agreed 100%

This is in there partially via the *.sublime-package files, but there's no reasonable way to distribute them.

When you install Sublime Text, a bunch of *.sublime-package files get added to C:\Program Files\Sublime Text\Pristine Packages. Each of these is just a simple zip file.

When you run Sublime, it compares all these packages with the ones currently in:
C:\Documents and Settings\Application Data\Sublime Text\Pristine Packages

Each new or modified package gets installed, also to the Application Data directory, but under the Packages folder. The basic process of upgrading/installing a package is to compare all the files in the old vs. new ones, and replace the on disk versions. Files in the older package but not the newer are removed.

What's missing here is the ability for packages to be installed without them having to first be under Program Files\Sublime Text\Pristine Packages - the plan is that eventually you'll just be able to download additional ones and double click on them in explorer.

There's also no easy way to create new packages yet, other than creating a new directory under Application Data\Sublime Text\Packages, and zipping it up.

[jps]

(For some context for viewers, PackageSetup.py lives in C:\Program Files\Sublime Text and is responsible for installing and upgrading *.sublime-package files)

You're right: PackageSetup will leave any files you (the user) have changed alone, unless they've also been changed in the package, in which case your local changes get nuked. This isn't much fun.

The very first improvement would be to make PackageSetup.py backup any files changed by the user, so worst case nothing is lost. This would be a huge improvement over the situation today.

The next thing that could be done is to try and do a 3 way merge between the old package file, the new package file, and the users changes. Some (much) earlier versions of Sublime did this (with the assistance of code.google.com/p/google-diff-match-patch/), but that wasn't conservative enough, and would try and merge conflicting changes, resulting in broken files.

Any merging must err on the side of caution in merging near-by changes, otherwise there's a chance that the resulting file won't be valid, and the user will end up with a broken installation - this is even less fun than losing your customisation to that file.

I'm not keen on making PackageSetup work via a version control tool, just because of the added complexity. However, as an individual, there's no reason not to put the C:\Documents and Settings\Application Data\Sublime Text\Packages directory under version control.

Actually, using some sort of VCS as the backbone of PackageSetup may not be a bad idea at all, as long as users are never expected to merge anything manually.

[SteveCooperOrg]

I'm tempted to try to get something up, but something very, very simple. Jon is likely to want the option of taking control of something like an add-in repository, and the more complex it is, the harder it will be for him to take over.

I'd prefer to start by dumping zip files on arbitrary FTP servers, and then telling people about them via the forum. Simple enough to start with. Also the way firefox does it... Source control is then up to the individual developer.

That said, I'm also tempted to put up a simple wiki to share coding tips and such. I may knock something up over the Easter weekend.

[jps]

Sounds great!

btw sublimator, there is a list of commands at sublimetext.com/docs/commands

[SteveCooperOrg]

One wiki, up and running! nothing impressive yet, but it's a start.

[sublimetextwiki.com](http://www.sublimetextwiki.com)

It's a moinmoin wiki, which seems to have some good buzz on the interwebs, but I've not used it before. Of particular interest is that it's written in python, and I thought that made sense for a python-addin website.

It's a straightforward installation so far, so we'll see if I can improve it as we go. It's text-file based, so at some point I'll be able to chuck a zip file of text files at Jon if he wants it.

[jps]

Great stuff Steve - just needs some content now

[SteveCooperOrg]

(speed) I've put it on fastcgi, I think, and it feels fast enough now.

(content) Content should now be king. My thought is to get some basic notes about customisation in there -- how do you map a key to a command? How does the macro system work? links to documentation on Jon's site. I think we should be looking at the emacs wiki as a role model. Here's a link to their mission statement. emacswiki.org/cgi-bin/wiki/MissionStatement

[SteveCooperOrg]

If I understand you right, S, we're talking about the ability to directly load from and save to an ftp server? That's something I'd definately want to see. As you say, if we can do it with a plugn/extension/macro/whatever, then I'm very happy with that. Anything to save me from my struggles with vi.

Did you have a method for doing it yet?

[jps]

Wiki is looking great - I'll add a link to in from the Support page.

re: content, tips n tricks, customisation etc are great - I'll be building the documentation at sublimetext.com into a reference primarily.

re: editing remote files, it's possible to get WinSCP to edit remote files in a standard editor, see winscp.net/eng/docs/task_edit#external_editors

[jps]

Right now the priorities as I see them (apart from plugin api):

1) Notice changes in files
2) Bracket highlighting

I agree with these, though with the addition of an easier way for people to edit basic settings (font etc).

[gordon]

I might try and whip up a snippet converter and convert some e/TextMate snippets.

Any possibility of supporting Textmate snippets directly, the way themes are? It would save a lot of work in the long run, I think.

[jps]

The snippet formats are very similar, it's something that will likely happen.

That'll probably be it for TextMate compatibilty though, as things like shell scripting for extensibility (which TM uses heavily) is not something I'm a great believer in, doubly so under Windows.