Some redesigning of the settings API

[SquidDev]

This is based on some of the comments in #351, and some other things I've wanted to do. There's a couple of things going on in this change:

• Add the ability to describe a specific setting. settings.define("my_setting", { ... }) allows you to provide a default value and description about a specific setting. This has several benefits:

  • /.settings now only stores options which have been changed, as the bios registers default values, rather than stating their value exactly.

  • settings.clear and settings.unset reset something to its default value, rather than clearing it entirely.

  • The set program can now print whether an option has been changed, and its description:

    

• settings.load/settings.save now default to /.settings

• settings.set and any other modifying function will fire a settings_changed event, with the arguments name:string, new_value, old_value.

---

I'd like to get some feedback from others before merging with this - there's definitely some design decisions I'm not happy with. As always, the PR can be tried online using cloud-catcher.

• settings.add is a bit of a confusing name. We probably also need a way to remove a setting's metadata, and really don't want to go with settings.remove.

• Firing an event whenever a setting changes feels somewhat inefficient, especially when doing bulk actions such as loading from /.settings. On one hand, this is exactly what the event system is for, but given that 99% of programs won't care about this, I wonder if there's another way. Ideas?

  The original issue (Settings API Improvements #351) suggested batching all changes into one single event. It works, but it also feels inelegant in its own way. Ughr, I don't know :).

[Lemmmy]

I wonder if settings.define and settings.undefine would be better names. This makes it clear that you need to explicitly define a setting for the computer to know about it's description.

I agree that batching things into a table doesn't feel very CC. Two alternative (but perhaps not any better) options come to mind, as food for thought:

• Register callback handlers instead of events (very not CC), e.g. settings.onChanged(function(setting, oldValue, newValue) ... end)
• A setting, off by default, for emitting settings events - settings.notifyChanges or settings.emitChangeEvents perhaps.

[JakobDev]

We could also add a type check for settings

[SquidDev]

Yeah, I did wonder about allowing some basic type = "string" field, but wasn't sure as some settings have dynamic types (such as string or nil). But even something simple would be a good start for now.

[JakobDev]

You can use a table type={"string","nil"}. it would also be nice, if we have custom types e.g. color.

[Lupus590]

Tables like the one @JakobDev described is how my arg validator works, if you want to take bits of that then here's a link to it.

[SquidDev]

I'm not entirely with some of the error messages, especially the ones that the set program spits out, but this'll do for now.