1.2 Released

[jps]

While I expect most forum readers are already using a beta version, for those that aren't, stable version 1.2 is now available. This encompasses all the changes in the beta between 20090210 and 20090620. Please read the blog for a summary of all the changes.

I'd like to thank everyone for all the suggestions, thoughts, bug reports, plugins and support on the forums. Without your collective encouragement, 1.2 would have never existed.

[jaydee]

Great! Thank you very much for this.

Note: You might want to update the site's download links with this, as they still point to 1.05

[jps]

Note: You might want to update the site's download links with this, as they still point to 1.05 :)

They do? They're linking to 1.2 for me... perhaps a caching issue?

[artee]

Thank you very much for all improvements
But...
The main problem with recent version of SB is IMNHO related to lack of documentation.
There were a lot of changes last time with not reflected documentation.
If Sublime claims to be an excelent editor for programmers it should provide well documented API, commands reference and so on.
For example, I'm going to create online theme editor for Sublime and I have a lot of problems with structure of theme file.
There is no information about list of valid keywords, or there are strange characters inside (see Doctype/XML Processing, Meta.tag, etc...)
The same situation is in documentation for snippets (are there any?).
Binding to keys were changed but there are no appropriate documentation for this.
Another problem is related to plugins because there is no information about version of plugin/snippet despite the list of them is growing up and it is hard to determine what was changed according to them in a new version. In my opinion there should be a field with this information in plugins API?
In conclussion, maybe this is a good time to tidy up whole project before another exciting features will be implemented

PS. If my theme editor will be done I'll share it with the community

regards,
Artur

[lbolognini]

Go upmod this guys:

http://www.reddit.com/r/programming/com ... n_windows/

Lorenzo

[lbolognini]

Do you have to join Reddit?

Yup! Maybe someone could also make a review/blog post that we could digg

Lorenzo

[EJ12N]

congrats on the stable release

[artee]

What do you mean exactly?

Typical software has a version number. Because the plugin is such piece of software it should contain this number.
If plugin is updated - revision is updated. Pretty simple
In the future, if Sublime will have hundreds of plugins it would be great idea to have option like Plugin manager where this revision number will be displayed and allow the user to update plugin package automatically (like PyPi).

A good practice for when updating sublime ( core or plugins ) is to have everything under version control.

It's a great idea. But I will prefer built-in mechanism.
Maybe simple revision control system should be included in core of Sublime?

regards,
Artur

[vim]

personally, one of the only things i feel sublime is not doing things right is with the plugin system. not that i am saying the plugins or other enhancement are not good, to the contrary, i love it, but their management is very poor.

in the past we had a discussion over it, and few of us (including me) said they use some kind of revision control for this. i feel this is not the right solution. let me describe some examples:

• i use CTags plugin, how can i know if i am up to date? how can i check the latest version, but also fall back if some bug slipped in?
• i wrote some snippets for erlang, will they be there (Packages/Erlang) also on the next version update? won't they be overridden? can i be sure? and if someone else just wrote snippet with the same name? and how can i even know if a new snippet with the same name exists already?
• why do i need the Groovy package (no offense groovy guys) if i don't even know for what it is?
• how can i distribute my snippets/plugins easily between my friends and co-workers? some of them wrote already their versions, how can they choose?
• i wrote a new package, do i need to zip it and expect them to extract it on %appdata%/.../Packages? and what if they and me still keeping adding changes? how will we merge it all? if we chose to use a revision control, do i expect from each of them to (1) svn update (2) copy to %appdata%/.../Packages (3) still, what about merges? or should they svn the appdata%/.../Packages itself?

i think that if we solve those issues, we'll have a dream-machine. as jon said, sublime is going to rely on enhancements, plugins, snippets. so their management should be a breeze, easy to pick and add, easy to use. last steps on the snippets, was wonderful, lets keep it up

vim.

[artee]

Where are you getting these plugins? As a sublime-package from the wiki or from the community repo?

I have no idea where, but IMHO it should be a common place like PyPi.
Plugins repository is growing up and due to the fact that most of them don't have any information about author, version and description it will be a problem in the future.
It would be a good practise to add the following variables to plugin body: __author__ and __version__.
Documentation can be done on module level (docstrings).

(For the moment) I'd recommend getting them as a subversion checkout where you can do things like `svn update and svn log`.

It's an excellent idea and it can be easily done by a programmer. Sublime is a text editor for programmers so geeks can have some problems with that