Some source release planned? :)

[Dev_NIX Coder]

There are a couple of bugs, and if I drop a folder in the project's sidebar, it doesn't anything. Do you have plans to have a source release? The community can help a lot! ;D

[Nick Tzanos]

At the moment, as Martin said in another post, you just need to create a new project and then drop any folders you want. But the functionality you ask for is already announced.
Being a personal text editor fan myself, and hearing this argument all the time, I do not really think that opening the source will change anything. I've seen it happen. If the main developers stop supporting a project, even if it is open source it very rarely gains any more features. On the other hand, I am very much favorable on the editor becoming actually extensible. This is where the community usually comes in. Even in "traditional open source" editors (or whatever you might want to call them) like Emacs and Vi(m), the community focuses almost entirely on extending the software with plugins, and not adding to the core functionality. The main developers for both are STILL there. This is what is upping the versions of the software. But having an extensible and well written product, then you can have a vibrant and active community extending the functionlity of the core product.

Just my two cents,

Nikos

[Martin "Cohen" Balazik]

I entirely agree with you there, Nick.

We are not planning to open source Intype at all. What we're going for is to add extensibility on three levels:

1. Basic: Extending Intype with simple bundles like snippets, grammars and themes.
2. Scripting: Allowing users to write advanced automation features using JavaScript API.
3. Native: A classic C++ based plugin API to be able to add some more system-resource demanding features.

With this scheme community will be able to actually extend Intype in anyway without actually working with the core. The core will stay "our" domain. As usual, we're opened for any feature requests for all of the APIs in these 3 steps and the plan is to make Intype awesome with the community, not just by ourselves.

Currently, the 0.9.4 release is to polish the Bundle Editor which currently works, but is not error safe as we would like it to be. When the BE is production-ready, we will push the manuals to help people creating their own bundles.

After 0.9.4, we're going to move to the second step: JavaScript. There is actually a lot of work done. This will allow people to do awesome automation stuff not only with editor, but also with the project and other "submodules" in Intype.

--
Martin "Cohen" Balážik

[Nick Tzanos]

Excellent, although Coffeescript would be another nice option, without the need for you to change your codebase.
Since I see a distinction between Scripting and Native, although I perfectly understand that they are two different things (being a dev myself), it would be nice to expose in the scripting API something more than just automation. I mean it would in essence be a choice whether I would like to write a plugin in JS or C++. The JS community is indeed much bigger, and using C++ would be nice whenever you need to add "external" functionality.

Just my 2 cents

[Martin "Cohen" Balazik]

We are considering CoffeeScript as well. :)

Essentially, we want most people to use JS to write their addons/plugins/automation, though stuff like custom parsers or text processing are much better task for C++. JS support is again split to several "APIs" which go from simple stuff (editing, HTTP, process) to complex (CommonJS compliance, custom UIs). These are going to be implemented step-by-step to keep as small amount of work per release as possible.

--
Martin "Cohen" Balážik