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
What’s going on with Editor 2??
There has been quite some time since we did a project update, sorry about that. The reason is of course that we have been really busy fixing issues that came up during testing (thanks everyone who is helping with that!!). One of the key things about Editor2 is excellent stability, so it doesn’t make sense to cut corners but fix everything properly in a sustainable way. We will spend three more weeks fixing these issues, and then tackle remaining features like bundling games and texture profiles.
Right now we are working on:
- Proper Windows 64-bit support - running the app in a 32-bit JVM puts it into compat-mode, with resulting issues like out-of-memory etc.
- Upgraded OpenGL libraries (JOGL) to counter driver issues - this caused Linux to crash at startup. A fix is being tested right now and will be released in a few moments.
- Device detection - we found some issues with the current solution and the fix should make the devices appear faster and “more often” than before. (The details are that we are now better at filtering out unwanted devices like printers and sound systems on the network).
- Command/Handlers - this is basically refactoring the internal system for handlers. Partly to make it more flexible and well-functioning, but also for future user extensions.
- Sync-dialog - minimise the risk of losing data when syncing files. This version is already much less intrusive in the local git repo, but in some instances like unexpected program termination, it might leave the files as stashed in git - which might not be very obvious to the user as it looks like the files are lost. This is about more easily getting back the files in these cases.
If you feel like helping out with testing, please send me a private message.
Have a nice gamedev weekend!
14 Likes
#teaserfriday!!
I couldn’t help myself yesterday and implemented a new feature, although we should be only focusing on fixing bugs right now. 
New menu items “Referencing Files” and “Dependencies” in the asset browser.
“Referencing Files” shows which files are using the file you currently selected:
“Dependencies” displays the opposite, which files the currently selected file is using:
That felt good!
18 Likes
It’s also time for a status update!
We will spend the remaining time of this year just fixing issues, i.e. holding back on new features in favour of stability. We still ensure compatibility for the new features developed by the core team (e.g. the upcoming label components and later 3d animation), so that you can open, save and build projects containing these features. We have updated the issues with the “serious” label, this means we will fix them during this time. If you have submitted an issue that does not get the “serious” label but you think it should, please explain to us why to help us understand.
- Windows 64 bit - all engine tests pass, but some remaining issues with Lua JIT
- Handler refactoring - nearly finished
- Github issues - 29 open (with “serious” label) - 82 closed
11 Likes
Referencing/Dependencies feature is really cool! 
I subscribed (to watch) to issues repository and really happy to recive messages about closed issues. 
9 Likes
loving that slick UI! can’t wait for it to come out!
4 Likes
Did I dream I saw a tweet about signing up for the beta, or have I missed it?
3 Likes
there is already a link for beta few comments earlier!
1 Like
ah yes, so there is. I was searching for the word beta 
2 Likes