I'm thinking about something like the following:

• Preference variables are registered through a function, like register_config_variable(key_id, group, name, type, ...). Session variables could use the same registration system with a different key_id. Maybe project files also.
• All registered variables would be loaded/saved with load_config(key_id) and save_config(key_id). (It would use something like for_each_config_variable.)
  • Adding and using a new variable would consist of adding it to the appropriate struct and registering it with the config management system. No more manually adding load/save code to separate functions. Existing structs would stay intact.
• Preferences could be set/get with something like get_config_variable(key_id, group, name) and set_config_variable(key_id, group, name, ...).
  • Existing code would continue to work. The registration system could use pointers to access the same variables.
• There could be a runtime override override_config_variable(key_id, group, name, ...) that sets an override flag so preferences can set sensitivity or display notices. It would also prevent writing override values to the config/session files.
  • Plugin identity could also be tracked, similar to plugin_signal_connect, so when the plugin is unloaded, the previous setting can be restored.

This could all be implemented in a plugin to manage its own settings as proof of concept to ensure that it makes sense before modifying Geany.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.