We had a meeting yesterday, one of the things brought up was that we need to be better at “expectation management”, and I’m the first to admit I’m not really good at that. 
It’s hard when you get really excited about stuff, like mr. Molyneux. 
Anyway, it’s great that you want to try it out! Just be aware that there is a lot left to do on it, quite rough around the edges so to speak.
6 Likes
So… Should we expect to use the new editor Friday, rough edges and all… or not? Here’s your big chance to manage my expectations ;p
3 Likes
Will the new editor have any of these debugging features?
-
Set breakpoints before/during debugging
-
Step in/over/out
-
Run to cursor, break and continue
-
Review call stack
-
Inspect/modify variables
3 Likes
As I wrote in the original post regarding this friday, the purpose is to get help testing and finding issues. For that reason it will not be open to everyone yet, to avoid misunderstandings of what it’s supposed to be and what the status is.
1 Like
Yes, but not for pretty long. You will still need to use ZeroBrane to have that functionality.
1 Like
We are now finally at a point where it makes sense to start the external testing phase. If you want to help out, we would greatly appreciate it. If so, send me a PM and I will give further instructions. There are still plenty of issues to fix and we hope you will find and report even more.
Some things to note:
- It’s not ready for efficient usage and production purposes
- Editor2 will send errors to sentry.io, without asking for permissions (not implemented yet)
- It helps if you are comfortable with git, or avoid pushing to your repository (data could be broken)
- It’s 100% compatible with Editor1, but bugs might make that statement temporarily false
A rough outline of the plan forward is:
- Fix issues
- Implement remaining features that we have in Editor1
- Release it for real
- Work on UX/workflow improvements
- Start working on larger new features
14 Likes
When do we join the Editor 2.0 party?
3 Likes
Hi. Out of curiosity: Will there be any way I can use Vim key bindings in the awesome-autocomplete-editor? Would be sad if I’d have to work in Atom to keep my muscle memory’s sanity and skip the autocomplete goodies.
1 Like
Hi! Right now the bindings are emacs/sublime-ish. Eventually we will support custom bindings but we haven’t decided to what extent. Vim with its modes is more of a challenge
1 Like
Cool. I’ve been thinking…
Actually, a more scalable solution for this problem would be to be able to use Defold’s autocomplete engine in any arbitrary text editor. That could be achieved by either decoupling the autocomplete engine from the Defold editor to be used as a library in whatever text editor plugin people might implement, either by implementing an API (localhost-bound HTTP or something) for a text editor plugin interfacing with the defold editor (kinda like how omnisharp-atom interfaces with an intellisense server).
I’m honestly willing to take up the project of implementing an autocomplete plugin for Atom if provided with an interface to Defold editor’s autocomplete engine.
Disclaimer: I in no way endorse trying to write Unity C# with omnisharp-atom. It’s a buggy, over-extending piece of crap that isn’t even working anymore.
2 Likes
I’d like to share a workaround about windows version of editor.
On weak systems (old notebooks and office-like pc-s) editor sometimes could not start, showing only a console window for a few milliseconds and then halting with an error :
Error occurred during initialization of VM
could not reserve enough space for 1433600KB object heap
The problem is: Java heap size used in default config.
If so, you can manually change the following line in Config file:
vmargs = -Xms1024m,-Xmx1400m,
This is a initial heap size (Xms) and maximum heap size (Xmx) in megabytes.
So, if your system have not enough free memory, java VM cannot run.
you can decrease this values to meet your system requirements.
for example:
vmargs = -Xms512m,-Xmx1024m,
3 Likes
Sounds like a fun and ambitious project
Our autocomplete engine is really nothing magical and we can’t prioritise creating a service out of it right now. Roughly what we do is parse any require’d modules (using antlr, I think the example Lua grammar will be fine) building a namespace/symbol table and then augmenting that with our built in functions.
Current info on our built in functions is published with every build. For info on how to fetch and parse it, have a look at @britzl dash-docset project https://github.com/britzl/Dash-User-Contributions/tree/master/docsets/Defold - in particular createdocset.py. @Lukas_Palmer made some notes about using Atom with Defold a while ago Big List of Lua Resources!, that might help.
2 Likes
Cool, thanks. I took an eye. Your docs seem more than parseable. 
It’ll make for a good side project. Maybe I’ll begin with a generic autocomplete-lua plugin and add Defold support to it. I found this lua AST parser for JS, so it seems like a doable project.
2 Likes
If you are looking for Defold support in Atom then please check this post: Defold docset for Dash
2 Likes
Thanks. Snippets are cool, but building a smarter autocomplete is better and more fun as a project.
3 Likes
What is the ETA for the new editor? I’m looking forward to the new features, and that sleek lights-out theme!
2 Likes
It’s actually already available if you are willing to help out as a tester: Defold Editor 2.0
3 Likes
Oh! That’s right, thanks! Might as well give it a go.
4 Likes