Lua Changelog

Lua
1

Since there’s likely going to be major changes in rapid succession, let me document them here as soon as I push them rather than requiring people to follow the commits.

All this applies to the Edge builds

3 Likes
2

API changes (important especially if you used the (Video) Demo and current state of Space Lua as a reference).

I’m still learning/exploring how to keep the global namespace somewhat clean, so therefore making some changes:

  • tpl for templates is now named template.new
  • define_command → command.define and with a slightly different API (see Space Lua)
  • define_event_listener → event.listen and with a slightly different API (see Space Lua)
  • tag → index.tag so this needs to be changed in all your existing Lua queries, likely.

Sorry for this, you will likely see a lot of Calling nil as a function style errors if you experimented with Lua before, but don’t see I didn’t warn you :slight_smile:

1 Like
3

Another thing that is technically not Lua related, but became a more obvious issue is how to do Library distribution and updates.

Until now, when you installed SB I basically would ask you to import the Core library, which would contain all basic templates and features you would generally want. From there, you could disable and overwrite things.

The new approach I’m trying out is to have a Library/Std library baked into the SilverBullet distribution. You don’t need to install it, but it’s just there as a part of the virtual file system (read only). There’s no files in your space, but they’re there in your page and meta picker. You also get the latest version distributed with your SB build. It’s similar to the built-in plugs.

The reason I’m going this way is that I want to implement more functionality in Lua directly. Two examples I am working on are:

  • The template system (APIs like template.each and template.new) are now implemented in “native Space Lua” rather than in TypeScript (as before), which I like because it makes the implementation more discoverable (you can just inspect it, although not edit it directly).
  • A set of default templates: basically reimplementations of existing slash templates like h1, hr, code etc, as well as TOC, linked references etc.
  • I’m looking at an alternative to configuration, and creating a Lua API for it. I also see no reason not to implement that API in Lua directly rather than TypeScript.

In the past one reason not to go this route was the inability to override “baked in” templates, however I think with Lua it’s fairly easy to allow overriding/tweaking/extending Lua-based APIs and templates from outside in a very natural way, so this is no longer a concern.