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.
These return values were wrong in the description and C example. As can
be seen on lines 2835 and 2873-2903 of src/core/wee-config-file.c the
callback_read function should return the same as the function
config_file_option_set plus the value
WEECHAT_CONFIG_OPTION_SET_OPTION_NOT_FOUND (which is also the same as
the possible return values of config_file_option_set_with_string).
The Python example was already correct and the C example was already
correct in the other languages apart from English.
These errors were introduced in commit 02e2b21d3 and commit 5210ff1ae.
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.*)"
Now the function utf8_char_size_screen can return -1 when the char is not
printable.
It has a specific behavior for some chars:
- U+0009: value of option weechat.look.tab_width
- U+0001 to U+001F (except U+0009): 1
- U+00AD (soft hyphen): -1
- U+200B (zero width space): -1
For buffers with formatted content, the "id" starts to 0 on each buffer and is
incremented on each new line displayed (it is reset to 0 if reaching INT_MAX).
For buffers with free content, the "id" is set to the same value as "y" (ie the
line number, starting to 0).
When logging this value I just see a number so I have to look up what it
means. Previously you would have to check the code or print the value of
each of these constants to see it. Seeing the value directly in the
documentation makes this much easier.
Trygve Aaberge