This updates the Python examples to include all the possible return
values for the callbacks in config_new_section, like it is done in the C
example. It also aligns the order of the values with the C example.
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.*)"
This makes it possible to see how functions are used without having to
go to the web page. It's especially useful to see the types of the
callback functions.
This is useful for two reasons:
1. When running unit tests for a script weechat needs to be mocked. By
having the constant values available in the stub file, they can be
loaded from that, instead of having to define the constants manually
for the mock.
2. If you log a constant value you have to look up what it means. This
makes it easier, in the same vein as PR #1824.
In Python raw strings, newlines can't be escaped with a backslash. If
you do that, both the backslash and the newline become part of the
string. This meant that the regex for constants both started and ended
with a newline which caused every other constant to be skipped.
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
Related: #1461
Some scripts (eg weechat-matrix) ship directories that need to be
imported from the script.
Rather than globally installing the python packages to python's
`site-packages` the directories can be installed alongside the script in
`WEECHAT_SHAREDIR/python`.
This change adds that directory to the `$PYTHONPATH` to import
successfully.
cmake documentation is absolutely atrocious, and I don't know why they
mention all the wrong things to use, and the cargo cult of successfully
writing a cmake build definition (copy-pasting what works from other
projects) also uses all the wrong things. But it turns out it is
possible to correctly link a PkgConfig target despite all that, at
least, *iff* you use cmake >= 3.13. I've chosen option 2, which is to
vendor in cmake >= 3.13's FindPkgConfig module in the previous commit.
Using IMPORTED_TARGET GLOBAL in a pkg-config check will result in a
proper linker target being created. For comparison, this is like using
meson's dependency() target, except meson forces you to do this by
default. The result is that the build system's internal representation
of how to link something, is used instead of manually passing build
flags defined in variables.
This is an important distinction to make, because cmake does not have a
list datatype, and instead turns lists into strings separated by ';'
which are indistinguishable from, like, strings which contain ';'
characters. When you pass the resulting list-which-isn't-really-a-list
to link an executable/library, you either need to preprocess the
variable to replace ';' with ' ' (just in case there are multiple
elements) or use cmake functions which magically know to do this
themselves -- or at least, I assume there are cmake functions that
correctly handle so-called "lists", or there would be no need for
"lists" to exist.
The IMPORTED_TARGET will define a bunch of INTERFACE_* properties which
do seem to do exactly this. The resulting build definition should
actually, correctly, link python, thereby fixing #1398 in a better way.
fixes incorrect (non)detection of libpython3.Ym.so due to PEP 3149 since
python's officially exported build flags know how to correctly link to
python.
Sébastien Helleu