Why not use debug()?

Comparing the debug() with trace() you can see that the annotations produced are identical.

However there is a subtle issue with the debug() function, it can block the use of the native Lua debug functions.

If you use a global debug() it will block the Lua debug functions, if you use a local debug() function it will not block.

We decided that it was best to stop using debug() altogether rather than muddy the waters by telling people that they could a local version but not a global version.

A little Lua background to explain what we are showing below. Lua stores its “global environment” in a table variable named _G. The _G variable is a Lua table that contains all of the global functions and variables. To inspect/investigate the global environment you just need to view the contents of _G.

So lets inspect the contents of _G:

Here you can see the that the Lua debug functions are available within the debug table _G.debug.

So lets create the global debug() function and show how it hides the _G.debug table by replacing it with a _G.debug function:

 

As you can see when you use the global debug() the table is replaced by the debug() function.

However if you use the local debug() the Lua debug table is still available:

Next: Support for editing file types other than Lua