From its very first version ZeroBrane Studio supported debugging of embedded Lua code; it was only a matter of adding
require('mobdebug').start() (when running on the same computer) and it would start a debugging session in the IDE.
There was one case though when it didn't work: if the environment that loads some Lua code doesn't provide a file name, the IDE doesn't have information about what resource to load for debugging. The simplest example to see this to try to try to do something like
loadstring("print(1); print(2)"). When this code is executed under the debugger, the source of this code is shown as
print(1); print(2). One workaround for this was to specify the second parameter to
loadstring: chunkname, which is then used by the Lua debug interface where it reports the source.
This workaround only works when you can modify the fragment that loads Lua code and in those cases where this is not an option (for example, when you need to use
luaL_loadstring, which provides no way to label the chunk with its file path) you were out of luck.
This situation has changed now. Starting from v0.38, ZeroBrane Studio provides a way to debug these code chunks without any additional configuration. When it gets a request that has a code fragment instead of a file name as its source, it will try to find an open editor with the content that matches that source and if there is no match will open a new editor and load the fragment in it.
This allows to use the debugger to "step into" calls to functions returned by
loadstring and also debug Lua scripts executed in environments like LuaJava. You can also look at the stack trace, set breakpoints, and use local console as you can normally do in the debugger.