I have a plugin that implements menu-hiding, multiple columns, and some other features. I'm thinking about submitting it here... How will updating it work? Will I have to submit separate PRs for each feature, or can I just periodically (monthly/yearly/?) push large changes?
Its not defined anywhere I am aware of, but my understanding is if you are the plugin maintainer its sort of up to you, you still have to make PRs so that the collection manager or someone else can check before merge it doesn't accidentally break the collection (the downside of everything being in one repository with a common build), but they have usually gotten merged fairly promptly then.
@elextr Does the Geany API have a way for plugins to check Geany settings (for conflicts), aside from trying to read/write the keyfile directly? I looked in the docs and through some of the headers, but didn't find anything. I might just be searching for the wrong keywords.
Depends on the setting, some are available in editor.h and document.h headers in the API. Others may not have been exported. Reading the keyfile is not reliable, Geany can write it at any point and AFAICT there is no signal to notify plugins. And don't forget some settings are overridden by the project file.
Better to ask for the setting to be added to the API.
To summarise, if its not in [here](https://www.geany.org/manual/reference/) plugins should not use it, even if they can.
@elextr An example would be for the auto-close plugin to be able to shut down Geany's built-in auto-close settings.
The structure containing the autoclose settings is in the API, but its members are deliberately opaque to plugins. So functions to manipulate those settings have to be added to Geany.
As a general rule structure contents should not be visible in the API as it will break the plugin ABI[^1] every time Geany changes the struct contents. Having getter and setter functions allows structures to change internally and for any Geany actions to be triggered when setting (for example making the autoclose settings in prefs dialog inactive if a plugin has disabled them). Not all Geany devs past and present have agreed with or conformed to this advice as you can see in the API :frowning_face:
A general note, Geany API is something that has grown over time, in general nothing gets put in the API unless asked for, so there is no consistency about what is available. Even more variable is what built-in functionality can be overridden by plugins, somebody has to want to do it and provide the PR to add it.
Finally getting to the point of the question, for autoclose maybe you can get away with just adding a bit to the autoclose bitmap indicating overridden by plugin and the Geany functionality in `editor.c::auto_close_chars()` can simply do nothing if the override bit is set. This means the users settings in Geany are not changed by the plugin, so no issues about saving/restoring them and only a `set_plugin_override_autoclose(bool)`[^2] is needed (you don't need a reader since the plugin can easily remember if it set it).
Extra marks if you make the prefs dialog indicate the settings are overridden by a plugin.
[^1]: breaking the ABI isn't a problem for those who can compile their own plugins, but it means all existing precompiled plugins will not load. It happened once that Debian released a new Geany which happened to break the ABI, but the plugins collection was delayed and suddenly users had no plugins as the old versions would not load. So we try and break the ABI as as little as possible, which means any structures in the API can't change often, possibly limiting Geany evolution. [^2]: better name needed
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.
I suggest you raise an issue on the Geany repo explaining your use case, the problems with the existing system, your proposal etc. and see what people say.
Are you aware of the stash system, how does this interact? Having a billion [exaggeration for effect] pref handling systems will make the code more difficult to follow than it already is.
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.
Plugins already manage their own settings, I'm not sure what you mean?
Plugins already manage their own settings, I'm not sure what you mean?
A plugin could use the proposed system just to demonstrate that it works. But it would be limited to changing its own settings. If it doesn't work, there would be no point pursuing it further.
It would be like implementing any other feature in a plugin to demonstrate that it works before moving it over to Geany. If the feature doesn't work or proves to not make sense, it can be abandoned without being ported into Geany.
Are you aware of the stash system...
I'm aware it exists, but haven't used it. The one time I tried, basically just copying and pasting the examples, I got a segfault I couldn't figure out how to fix. I did write the earlier description with the understanding that it likely replicates existing functionality or could be implemented by modifying existing functions. Looking at the stash system again, it looks like it would just need to have some lookup and override features added.
#1138
Closed #1131.
github-comments@lists.geany.org