Defold Editor should drop the code editor

Feature requests
#1

that’s not true, the title is just a clickbait. I don’t think it really needs to be dropped.
but in general I am convinced that good software must do one thing and do it well.
and the core business of defold is not being a code editor. therefore I think that defold, in addition to the basic editor (which already exists) should offer native integration with a real code editor.

I know the work of astrochili exists but it’s hackish. on windows you need to install bash and personally after using it for a couple of days I had to uninstall it because randomly vscode would start using huge amounts of memory and then becaming impossible to close.

that’s probably a good start, but I think it should be driven by the defold devs, not the goodwill of a user.

defold’s internal code editor is quite primitive, lacks features that are today considered normal in a code editor, and even with all the efforts, it will never be able to compete with vscode or similar

furthermore, by reducing the effort on the internal code editor, the development team could focus on more core aspects of the engine

tl;dr: a proprietary basic code editor is fine, but I think we need a native integration with a real code editor, like vscode. it’s basically what unity did years ago with visual studio.

p.s. the exposition is deliberately ‘bold’ to spark the discussion but the truth is that it’s obviously just a humble and naive opinion from someone who started playing with defold a few days ago. and I have to say that in general I really like defold and I continue to be amazed at how much everything is ‘how I wanted it to be’ in the tools I’ve used in the past.

3 Likes
#2

I disagree with many of the points made here. Here are my rebuttals:

Do you have any examples? I’ve used VSCode at work and for side projects for several years. I’m actually impressed at how good Defold’s script editor is in comparison. It even has some of the more QoL features like box-select, tab / shift + tab for indenting or un-indenting multiple lines simultaneously, custom color schemes, etc.

Keep in mind that VSCode was built as an editor to support all kinds of software development. Defold’s script editor is specifically for editing relatively small Lua scripts, which it excels at. It is unwise to expect similar features across the board. The two code editors are not trying to compete and should not attempt to because they were made to solve different problems.

I could be wrong, but I believe the Defold team just hired on a few people to work specifically on the editor. So stripping the script editor would not free them to work on the engine itself. Instead, if you have improvement suggestions, let the team know and they might be able to add them.

In my opinion, the script editor is extremely handy. It is convenient to have it available whenever I need it without needing to open a secondary piece of software to edit my game. (This is something @britzl mentioned in one of his recent live talks – the editor is a one-stop shop with everything you need to make a game.) Stripping the editor would hinder the development process.

To be honest, it sounds like your opinion is mainly driven by this:

…which in some ways is a reasonable philosophy, but you’re talking about a full game engine and its corresponding editor. If you strip the script editor, you still have a massive piece of software doing all kinds of things. Script editing is just a tiny piece of that.

I do not mean to be rude, but I think you should think more deeply about what that line really means. It cannot be applied to all software and is more often used in reference to particular function calls, classes in OOP languages, etc.

Perhaps what you really meant to say with your post is “I would like to see more compatibility with external code editors, like VSCode.” This would be a reasonable suggestion and some people might actually agree. Maybe an “open in [your default editor of choice]” button? Note that plenty of people in the Defold community are currently using Defold and VSCode together already and have been for at least a couple years now. I can’t remember who exactly as it has been a while since I’ve seen mentions of it.

11 Likes
#3

I do not fully understand what you are asking for.

What does this really mean?

Also, what are the things in VSCode that you are missing from the Defold editor?

I personally don’t like VSCode. I prefer Sublime Text. I used to like Atom, but it’s a bit slow at times. Should we start supporting all three? Perhaps also others (there was a discussion recently about support for Vim)? By picking one and focusing all our efforts on it we may alienate users who prefer another editor.

4 Likes
#4

Just to chip in on this, I like the built in editor and the “everything in one place” ethos. External tools tend to add steps to the workflow, which I’m not a fan of.

Since we’re on the topic, one feature I’d like to see in the built-in editor is improved code completion for lua modules. Support for self variables (M.FOOBAR) would be handy. Also, the existing code completion for lua modules doesn’t work sometimes, I believe it’s when the script file has specific errors.

6 Likes
#5

The Lua Linter we’re working on (or actually full LSP support) will help with this and much more! I expect to see great improvements this year!

10 Likes
#6

Personally I like the ‘batteries included’ editor as it doesn’t require me to set-up additional tool chains, dependencies, build pipelines, etc and it allows me to get a project up and running in a minutes.

I do wish the editor was a little more performant as there’s always a little lag (I’m on an M1 Pro, 32GB) when opening files, navigating project settings, etc. I’d also love to be able to drag and drop things a little more; images into atlases, scripts onto objects, etc, and having some additional animation tools would be most welcome. I’ve often thought of looking how I could add little extensions to the editor, but Clojure does my head in.

4 Likes
#7

I enjoy using VSСode as a universal editor where I can work with all kinds of files, customize my usual hotkeys, customize the appearance, set the necessary extensions. Everything works quite smoothly and quickly for me and I haven’t noticed any memory leaks. I’ve been friends with this editor since it was the first normal code editor for Unity on macOS (2015-2016?)

It was the only code editor that allowed me to edit a 200mb raw database file by quick search and replace with regex and it didn’t lag at all.

This may sound unusual, but I am using color theme and icons from Atom, because visually the standard Atom theme inspires me more, from the time when I wrote a game with it and love2d framework.

When I have to work with raw lua modules, without Defold, running it directly in VSCode with debug, I’m having a lot of fun.

But from observation, most people prefer other solutions, so you can say that it’s just my taste. I can’t afford to say what is right or wrong. What seems very convenient to me is not convenient for everyone.

On the other hand, this does not cancel all the coolness of the utility, which was even put on github.dev.

5 Likes
#8

Uuuuu. I hear LSP, I press like. Autocomplete and linting through LSP would solve 90% of the cross-text-editor support issue. Yes, we can use luacheck and sumneko/ lua-language-server, but the main hurdles with those is that they can’t see files in Defold’s dependency .zips.

DAP support for debugging would also be a great bonus feature. Otherwise, a way for an external text editor (maybe through the LSP somehow) to trigger hot reload on a file or to start the game would really be everything that’s needed for a comfy external editor experience.

Then you can leave plugins for various editors to the community (I for sure would make one for Vim and maybe VSCode too).

8 Likes
#9

As others I don’t fully agree.
I like the integration of the editor but I agree it lacks in comparison with vscode or nvim. LSP is for sure going to provide a big step forward but there are other bits and pieces that I would love to see like custom key shortcuts and opening it up to editor extensions via lua.
I know you guys have it on your radar, it will get there I’m sure :slight_smile:

2 Likes
#10

maybe I can create an issue in your repo and describe what happens to me. for me the problem is reproduced systematically and unfortunately it makes the solution unusable, which otherwise would be ideal.

1 Like
#11

I realize that opinion is not popular and that’s fine. I also see now that, on this subject, the defold team has works in the pipeline, which go in the diametrically opposite direction to what I am suggesting and that closes the case.

Moreover, risking irritating the devs with criticisms, especially at the beginning when I’ll probably need support is a very bad strategy :slight_smile: so I’ll try to clarify what I meant but won’t push the matter further

and I apologize for the length

means that defold should officially offer and support a solution like the one published by astrochili

A way to seamlessly have a development environment that supports debugging.
It could be exactly or a fork of that of astrochili, but the official support would mean that it is maintained by defold, it is guaranteed to always function and its maintenance does not depend on the free time/will of a single user

there is a spectrum of things ranging from fundamental functionalities to simple QoL improvements.

  • autocomplete, api discovering: autocomplete doesn’t always work. when it works it doesn’t display any documentation of the method.
  • project wide code navigating code - goto implementation. move to previous
  • project wide refactorings
  • conditional breakpoints
  • better debug value inspector
  • better git integration
  • ability to customize keyboard shortcuts, color schemes
  • all the action found in the ‘Selection’ menu of vscode

I love sublime too. if the debugging experience (never tried the debug package), refactoring, navigation are adequate it could be just fine as well. I suggested vscode because 1) it’s free 2) it runs everywhere even on the washing machines 3) a solution using it already exists

of course you can’t support everyone and you can’t make everyone happy
but you’re not taking anything away, you’re just adding an ‘optional’ piece. this shouldn’t alienate users

for me

  • defold’s internal text editor is definitely useful and stays. for many it is enough. in the future no major efforts are made to extend it
  • also remains the possibility to specify another text editor, as it is now. one can put sublime or notepad++ or whatever he wants. there is obviously no debugging supported
  • additionally, an official integration with vscode, supporting debugging and everything described above

To me this became clear upon reflecting on the fact that unity, despite the workforce available, and despite their strategy of often bringing everything ‘in-house’ has decided that it was not worth having a proprietary development environment. Their internal text editor is minimal. you can specify any text editor you want. but with visual studio there is a special relationship, where debug works.

Can the above things be implemented internally in the defold editor as well? surely.
Is it worth it? I say no, it’s effort ill spent.

4 Likes
#12

No no. I can assure you that we can stay objective. Constructive criticism is good. Thank you.

I’ll discuss this with the rest of the team when we meet in person on Thursday next week (we usually work remote but meet in person every other Thursday).

1 Like
#13

That link you posted is broken.

#14

fixed

#15

Since most people seem to be disagreeing with ekt, I’ll throw a little support. I agree with about everything said in the last post (answering the questions.) The integrated editor is okay to have but it really noticeably does not have the features VSCode has. Another thing in addition to the list above is hover code docs, just off the top of my head. And I like being able to have my editor on a separate monitor from engine and other tools (as far as I can tell I can’t move that tab out of the defold window.) I also like to be able to have more than 2 tabs visible at once (as far as I can tell can only ‘move to other tab’ and back.)

When I first started playing with defold I quit a couple times just because I didn’t like the coding experience. I’m mostly okay with it now because I use VSCode by just copying the defold_api folder from the guide to my projects but this is not exactly a perfect solution. And I noticed when I set Defold to use an external editor, it works okay but it cannot open builtins anymore (they don’t open in VSCode nor the editor in the engine at that point.)

In the end I’ve found a solution that is comfortable for me so it isn’t a big deal but at this point I also find the in engine editor almost useless unless I want to look at builtins. (I feel the same way about Godot’s in engine editor too… but that’s beside the point.)

I just copy that folder and leave Defold to open scripts in Defold. So when I code I just use VSCode like I normally do in a separate window from Defold. Works pretty well. Though having to manually copy that defold_api folder to the project is not so cool.

4 Likes
#16

Which folder is this?

I wonder if this is something that can be improved in the VSCode extension somehow? Could the VSCode extension somehow include an unzipped version of builtins? Or possibly if VSCode could show and work with contents of zip files? If that is the case then VSCode could work with both builtins.zip and any dependencies added to the project.

1 Like
#17

It’s safe to say that VS Code is the most popular code editor (not taking into account Xcode, Visual Studio or Android Studio). Sublime also offers a similar level of functionality, I think if either of them is supported officially that would be great.

It would certainly be beneficial for newcomers to feel like at home when trying Defold.

As for me I’d like an easy way to trigger the build process from VS Code (not bob) and to see debug/compilation errors in the VS Code console. And to open files in VS Code when clicked in the editor.

The built-in editor should not be abandoned of course. But having an external editor option like in Godot would be really nice.

7 Likes
#18

https://github.com/astrochili/defold-vscode-guide is more of a guide to set up a project for use in VSCode than an actual extension (if I remember right… been a while since I did it.) One of the steps is to essentially copy a few things from its template (or start a project from it.) There is a .defold_api folder that has a bunch of lua files in it that represent the defold API (I think.) This is what gives VSCode the ability to do auto completion and has hover docs and such if I’m not mistaken. In the end I didn’t really need most of the stuff in the defold-vscode-guide, so all I do now is copy this folder into the root of my projects. The VSCode extensions the guide suggests are actually unrelated, general lua extensions.

#19

I need to better understand this. There is a template project and setup instructions by @astrochili. What is lacking from this besides the fact that it is a Defold user and not the Defold Foundation which created it?

Also it is open source which means that anyone (including you and me) can help improve it, even if @astrochili loses interest. I would in fact encourage anyone having opinions about the current VSCode support to get involved and help improve it.

What we (the Defold Foundation) can do right now is to add VSCode setup instructions to the official documentation and help promote this integration.

4 Likes
#20

Yes, being from, supported and promoted by the Defold Foundation is the main difference and desire.
Lacking:

  1. Run project (not bob.jar)
  2. Set VS Code as an external editor from a dropdown as opposed to filling the path to the editor.

image
image1050×662 60.5 KB

2 Likes