Make individual scripts the unit of ownership for theme contributions
so that loading a script that calls weechat.theme_register(...) and
later unloading it correctly removes the script's overrides.
Plugin API addition (weechat-plugin.h):
- new function pointer t_weechat_plugin.theme_unregister_script
delegates to core's theme_unregister_script.
- new convenience macro weechat_theme_unregister_script(script).
- WEECHAT_PLUGIN_API_VERSION bumped to 20260527-02.
Script API additions (plugin-script-api.{c,h}):
- new plugin_script_api_theme_register (plugin, script, name,
overrides) forwards to the plugin API with the script pointer
as the contribution owner, so contributions are tracked
per-script (not per script-language plugin).
Lifecycle wiring (plugin-script.c):
- new file-local plugin_script_remove_themes (plugin, script)
calls weechat_theme_unregister_script.
- plugin_script_remove now calls it alongside the other
plugin_script_remove_* helpers, so script-unload tears down
everything (configs, bar items, themes, hooks).
Eight language bindings updated to call
plugin_script_api_theme_register instead of weechat_theme_register
directly, so they pass the script pointer as owner:
- python, perl, ruby, lua, tcl, javascript, php, guile.
The behavior change is end-to-end visible only at script unload:
before, an unloaded script's theme overrides lingered in the
registry forever and would be re-applied on the next /theme apply;
after, they vanish when the script unloads. /plugin unload of an
entire script-language plugin already worked via commit 24's hook
in plugin_remove (which drops both plugin-only contributions and
their script-owned children when the language plugin itself goes
away, because the contribution's plugin pointer matches).
No new unit tests in this commit: the underlying theme_unregister_script
function is covered by TEST(CoreTheme, UnregisterByOwner), and the
remaining changes are plumbing.
Add weechat.theme_register (name, overrides) to all eight script
languages. Each binding is a mechanical translation of the same
signature:
- name: string
- overrides: language-native dict / hash / associative array of
full_option_name -> value strings
- returns: pointer-as-string of the registered t_theme (empty
string on failure)
Each binding converts the dict to a struct t_hashtable using the
existing per-language helper (weechat_python_dict_to_hashtable,
weechat_perl_hash_to_hashtable, weechat_ruby_hash_to_hashtable,
weechat_lua_tohashtable, weechat_tcl_dict_to_hashtable,
weechat_js_object_to_hashtable, weechat_php_array_to_hashtable,
weechat_guile_alist_to_hashtable), calls weechat_theme_register,
frees the temporary hashtable, and returns the result. The new
function is registered right after the config_* functions so the API
listing stays grouped by topic.
PHP also receives a new arginfo entry (string, array -> string) in
both weechat-php_arginfo.h and weechat-php_legacy_arginfo.h.
This is plumbing only - the underlying theme_register function is
already covered by tests/unit/core/test-core-theme.cpp
(TEST(CoreTheme, Register)). No script-side tests are added here.
The callback_read and callback_create_option functions in the scripting
APIs always get the value as a string, never as null. This means that if
the value is null, there is no way for the script to distinguish this
from an empty string for string options. This makes it impossible to
properly make options with fallback values, like the irc server and
server_default options, as far as I can see.
All the scripting languages except Tcl use that language's equivalent
for null. For JavaScript which has both null and undefined, null is
used. For Tcl, the magic null string defined in commit 197a7a01e is used
and the documentation is updated to describe that.
I tested this with these scripts:
https://gist.github.com/trygveaa/2d49c609addf9773d2ed16e15d1e3447
You can load all of those scripts and see the result with this command
(assuming you have the scripts in the current directory):
weechat -t -r "/filter add script * * script; /script load $(echo script_config.*)"
The plugin API function config_new_option accepts null as the
default_value and/or value however the scripting APIs (except for lua)
didn't allow sending null as a parameter value, so it was impossible to
use it this way. This allows sending a null value for these parameters.
Lua already supported sending in nil for these parameters and it works
as expected, so nothing is changed for this plugin.
For Guile you can now send in #nil, for JavaScript null or undefined,
for Perl undef, for PHP NULL, for Python None, for Ruby nil and for Tcl
$::weechat::WEECHAT_NULL.
In all of these languages except Tcl this is the special value
indicating a missing value. However Tcl only has one type, string, so it
doesn't have a null value. Therefore I created a constant with the value
`\uFFFF\uFFFF\uFFFFWEECHAT_NULL\uFFFF\uFFFF\uFFFF` which is used
instead. This is very unlikely to appear unintentionally. Using the
unicode code point \uFFFF was suggested on
https://wiki.tcl-lang.org/page/null.
I tested this with these scripts:
https://gist.github.com/trygveaa/f91977dde5d2876d502bf55fbf9b50cc
Sébastien Helleu