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
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
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
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:
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).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.
Ok, sorry another big breaking Lua API change. Since Lua seemed to use the snake_case convention for APIs, that’s what I opted for in SilverBullet as well. However, this wasn’t sustainable due to interoparability with internal APIs (syscalls specifically). I’ve also since found out that many bigger Lua frameworks use camelCasing as well. Therefore I decided to rip the bandaid and expose all syscalls and update all predefined APIs to use camelCase now as well.
This will be live on the Edge soon and will likely break some of your stuff if you rely on some syscalls with underscores in the name. Sorry about that, but I felt it needed to be done.
As soon as this goes live, silverbullet.md will have all docs and examples updated (to the best of my ability).
To also post better news: you can now use Lua directives in (old style) templates.
```template
10 + 2 = ${10 + 2}
```
Should also work in widgets etc.