I’m suddenly getting this error below based on the further below space-lua config. I hadn’t changed anything recently to cause the issue (that I remember!). I’m getting at least 10-15 similar errors when the client loads.
Any thoughts on what’s going on?
[Client] Statement errored out during boot, but ignoring: command.define {
name = “Custom: Toggle Task”,
description = “Toggle between task or not”,
key = “Ctrl-Shift-t”,
run = customToggleTask
} Error: Attempting to index a nil value
function customToggleTask()
local line = editor.getCurrentLine()
local text = line.text
if string.startsWith(text, "- [ ] ") then
-- Remove the task prefix
editor.replaceRange(line.from, line.from + 6, "")
else
-- Add the task prefix
editor.insertAtPos("- [ ] ", line.from)
end
end
command.define {
name = "Custom: Toggle Task",
description = "Toggle between task or not",
key = "Ctrl-Shift-t",
run = customToggleTask
}
slashcommand.define {
name = "Custom: Toggle Task",
description = "Toggle between task or not",
run = customToggleTask
}
Ok I understand this is confusing, but it should be harmless, you can ignore these errors. I’m guessing you’re defining some custom commands in your CONFIG page?
Some background on what’s happening here: to support certain new configuration options (specifically around indexing and sync) I now have to load your CONFIG file when the client boots, way before the whole editor is ready. The way I do this is by running the Lua code in the CONFIG page with some very limited set of APIs exposed (mostly only the config.* ones). Everything else is not yet available and will therefore fail “quietly” (the “but ignoring” is the quiet part). Later on, the full config is loaded properly and these errors shouldn’t reappear.
What of course is confusing here is that you still see those errors, so perhaps I’ll just hide them completely or mark them even more explicilty “THIS FAILED BUT IT’S OK!!!11” I’ll think if I’ll just mute errors entirely for a future release.
If you don’t like these errors, or perhaps even as a better practice: what you can do is simply move anything that’s not config.* calls from your CONFIG page to a separate page, e.g. Library/Commands, or call it whatever you like the name doesn’t matter. That should solve the issue (and may be cleaner anyway).
what you can do is simply move anything that’s not config.* calls from your CONFIG page to a separate page, e.g. Library/Commands, or call it whatever you like the name doesn’t matter. That should solve the issue (and may be cleaner anyway).
This!
We should maintain some BCP in docs to avoid common flaws, by the way…
Well, I think this, and perhaps few other things, could be solved if we indexed the Space Lua and Space Style scripts, including page and tags. Together with the priority comments it seems like as powerful to avoid most loading and syncing quirks. (Just an idea, again.)
All that is indexed, and this is also how space lua is generally loaded (straight from the index). However the case I had to cover is the initial sync case: fresh browser, nothing there. How do I now know what files I need to sync if there’s configuration options that can change this buried all over your space? Same for indexing, how do you configure the indexer if it hasn’t indexed the configuration options yet Bootstrapping problems.
In the end the best I could come up with is to assume these options all appear in CONFIG and preload them from there. Not super excited about this solution, but don’t see a better solution that doesn’t involve going back to a server-side indexing model again.
Ah, thanks for the detailed explanation. I was debugging something else and ran down the rabbit hole of these harmless errors (I had found out the commands still worked even though the console errors).
For me, debugging Lua in SB is relatively hard, only having the character number to start the search. These additional console messages do clutter/confuse up the logs. Hiding them on first parse/load/bootstrap process does make sense. ([Client] Error evaluating script: Attempting to index a nil value at [[CONFIG@1130]], um ok… where/what is that?!, opens up the file in vim, :1130goto)
Perhaps though this is part of a larger anti-pattern. If only config should be in CONFIG.md, then a gentle user nudge could steer in that direction, ie "CONFIG.md is for configuring SilverBullet. For user commands, keyboard shortcuts, and functions, we suggest you put these in Library/Commands, Library/Keyboard, etc for organizational purposes.
Steering isn’t quite a silverbullet for these cases though
I’ll think if I’ll just mute errors entirely for a future release.
