Theme files saved with /theme save and automatic backups now always
contain every themable option (full snapshot), so a theme file is
self-contained and round-trips exactly regardless of the current
configuration. The diff-only mode and the "-full" argument of
/theme save are removed.
Detect the terminal background (via COLORFGBG or an OSC 11 query) before
GUI init and, on the first start, automatically apply the built-in
"light" theme when a light terminal is detected.
The function gui_term_theme_is_light returns an int (1 if light, 0 otherwise,
0 being the safe value when detection is unsure).
Add six entries to the "Added" section of Version 4.10.0 in
CHANGELOG.md:
- the /theme command with its subcommands (list/apply/save/delete/
info) and the automatic backup mechanism, plus the shipped
"light" built-in theme;
- the themable flag on configuration options;
- the weechat.look.theme and weechat.look.theme_backup options;
- the theme_register plugin/script API function;
- the t:themable filter in fset.
No UPGRADING.md entry: the change is purely additive — default option
values are unchanged, so existing users see no visible difference
until they explicitly /theme apply light. weechat.look.theme is a new
option (empty by default at first launch) and weechat.look.theme_backup
defaults to "on".
Add the "Themes" section to user guides and plugin API references in
every language where the corresponding adoc exists.
User guide (10 files): English (the new prose) and French (a full
translation, with section title "Thèmes"). For the other languages —
German, Italian, Japanese, Polish, Serbian — the body is the English
text with only the section title localized where the existing Colors
section is localized (Themen / Motywy / Теме); Italian and Japanese
keep the English "Themes" title to match their existing English-only
section titles. Coverage by file:
- doc/en/weechat_user.en.adoc (new English section)
- doc/fr/weechat_user.fr.adoc (full French translation)
- doc/de/weechat_user.de.adoc (English body, "Themen" title)
- doc/it/weechat_user.it.adoc (English body and title)
- doc/ja/weechat_user.ja.adoc (English body and title)
- doc/pl/weechat_user.pl.adoc (English body, "Motywy" title)
- doc/sr/weechat_user.sr.adoc (English body, "Теме" title)
Plugin API reference (5 files): same approach — English plus full
French translation; Italian, Japanese and Serbian keep the English
body with their conventional section title:
- doc/en/weechat_plugin_api.en.adoc (new English section)
- doc/fr/weechat_plugin_api.fr.adoc (full French translation)
- doc/it/weechat_plugin_api.it.adoc (English body and title)
- doc/ja/weechat_plugin_api.ja.adoc (English body and title)
- doc/sr/weechat_plugin_api.sr.adoc (English body, "Теме" title)
User-guide content covers themable options, /theme apply with the
automatic backup mechanism, /theme save and /theme delete with the
reserved-name rules, the .theme file format with a sample, and the
user-file-shadows-built-in resolution order. The API-reference content
documents weechat_theme_register (prototype, arguments, return value,
C example, Python example) with notes on the themable flag and
per-script auto-cleanup on script unload.
The /theme command's CMD_ARGS_DESC help text and the cmdline option
descriptions are picked up automatically by the doc generator
(doc-autogen), so no manual entries are needed there.
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.
Call theme_unregister_plugin (plugin) from plugin_remove, right after
config_file_free_all_plugin and before unhook_all_plugin. This drops
every theme contribution whose plugin pointer matches the plugin being
unloaded, so subsequent /theme apply runs no longer try to set
options for an unloaded plugin and per-plugin contributions don't
outlive the plugin.
Script-owned contributions (plugin != NULL && script != NULL) are
left intact - they are cleaned up per-script in the next commit.
This commit is wiring only: the underlying theme_unregister_plugin
function and its semantics are already covered by
TEST(CoreTheme, UnregisterByOwner) in the previous commit.
Refactor the theme registry to store one sub-table per contributor
instead of a single merged hashtable. Each registered theme now holds
a linked list of t_theme_contribution entries:
struct t_theme_contribution {
struct t_weechat_plugin *plugin; /* NULL = core */
const void *script; /* NULL for non-script */
struct t_hashtable *overrides;
...
};
Identity of a contributor is the (plugin, script) pair:
- (NULL, NULL) -> core (theme_builtin_init)
- (plugin, NULL) -> plugin-level contribution
- (plugin, script) -> individual script (filled in by next commit)
theme_register is now (plugin, script, name, overrides). It searches
the existing contributions for a matching (plugin, script) and merges
the new overrides into it; otherwise it appends a fresh contribution.
The public macro weechat_theme_register(name, overrides) still takes
two args - it now expands to pass weechat_plugin and NULL for script.
theme_apply iterates contributions in list order, calling
config_file_option_set for each entry; later contributions naturally
win for duplicate keys.
Two new internal helpers prepare for the lifecycle work in the next
two commits:
- theme_unregister_plugin (plugin): drops every contribution owned
by that plugin (with script == NULL).
- theme_unregister_script (plugin, script): drops every contribution
owned by that script.
Neither is called yet; the auto-purge wiring lands in commits 24
(plugin_unloaded signal) and 25 (script API + script-unload hook).
Other touched code:
- core-theme-builtin.c switches to theme_register (NULL, NULL, ...).
- core-command.c /theme info uses theme_overrides_count helper
instead of reaching into theme->overrides (which no longer
exists).
- WEECHAT_PLUGIN_API_VERSION bumped to 20260527-01 (function-pointer
signature change).
Two new tests cover the new semantics:
- UnregisterByOwner: registers four contributions from distinct
(plugin, script) pairs, then prunes by plugin and by script,
asserting per-contribution removal.
- RegisterMergesPerContributor: two successive register calls from
the same (plugin, script) merge into a single contribution with
later keys overriding earlier ones.
Existing tests are updated to use the new theme_register signature,
theme_overrides_count, and theme_get_override (replacing direct
access to theme->overrides->items_count and hashtable_get on
theme->overrides). No plugin or script call sites change - the
public weechat_theme_register macro keeps the same shape.
Add trigger-theme.{c,h} with the trigger plugin contribution to the
built-in "light" theme: 6 entries (flag_command, flag_conditions,
flag_post_action, flag_regex, flag_return_code, regex) tuned for a
light-background terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add spell-theme.{c,h} with the spell plugin contribution to the
built-in "light" theme: 1 entry (spell.color.misspelled=red) tuned for
a light-background terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add script-theme.{c,h} with the script plugin contribution to the
built-in "light" theme: 24 entries on script.color.* (status_* and
text_*) tuned for a light-background terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add relay-theme.{c,h} with the relay plugin contribution to the
built-in "light" theme: 5 entries (status_auth_failed, status_authenticating,
status_connecting, status_disconnected, text_selected) tuned for a
light-background terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add logger-theme.{c,h} with the logger plugin contribution to the
built-in "light" theme: 2 entries (logger.color.backlog_end=darkgray,
logger.color.backlog_line=darkgray) tuned for a light-background
terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add exec-theme.{c,h} with the exec plugin contribution to the built-in
"light" theme: 2 entries (exec.color.flag_finished=red,
exec.color.flag_running=green) tuned for a light-background terminal.
Same 2D-array pattern as the other plugin contributions.
Default option values are NOT changed.
Add xfer-theme.{c,h} with the xfer plugin contribution to the built-in
"light" theme: 7 overrides on xfer.color.* (status_aborted,
status_active, status_connecting, status_done, status_failed,
status_waiting, text_selected) tuned for a light-background terminal.
Same NULL-terminated 2D-array pattern as the irc, fset and buflist
contributions; xfer_theme_init() is called once from
weechat_plugin_init after xfer_config_init / xfer_config_read.
Default option values are NOT changed.
Add buflist-theme.{c,h} with the buflist plugin contribution to the
built-in "light" theme: 5 overrides on buflist.format.* options
(buffer_current, hotlist_low, hotlist_message, lag, number) tuned for
a light-background terminal. Each target is a "string|themable" option
holding an evaluated format expression with embedded ${color:...}
references.
Follows the same pattern as the irc and fset contributions: a
NULL-terminated 2D string table consumed by a tiny local register
helper that builds a hashtable and calls weechat_theme_register;
buflist_theme_init() is called once from weechat_plugin_init after
buflist_config_init / buflist_config_read.
Default option values are NOT changed.
Add fset-theme.{c,h} with the fset plugin contribution to the built-in
"light" theme: 47 overrides on fset.color.* options (line backgrounds,
selected-row tuning, title and value colors) tuned for a
light-background terminal.
The table is a NULL-terminated 2-column array of strings (no struct
wrapper, matching the pattern adopted for the irc contribution).
fset_theme_register builds a hashtable from the table and calls
weechat_theme_register; fset_theme_init() is called once from
weechat_plugin_init after fset_config_init / fset_config_read.
Default option values are NOT changed.
Add irc-theme.{c,h} with the IRC plugin contribution to the built-in
"light" theme: 9 overrides on irc.color.* options tuned for a
light-background terminal (input_nick, item_lag_finished,
item_tls_version_deprecated, list_buffer_line_selected,
message_chghost, message_setname, nick_prefixes, topic_new, topic_old).
The registration is a small wrapper around weechat_theme_register that
builds a hashtable from a static (option, value) table and frees it
after the call. irc_theme_init() is called from weechat_plugin_init
after irc_config_init/read so the option names are already created
when the theme registry references them.
Default option values are NOT changed.
Add a small core-theme-builtin.c module containing the core
contribution to the "light" theme: 33 overrides for
"weechat.bar.{status,title}.color_*" and "weechat.color.*" tuned for
light-background terminals.
theme_builtin_init() builds a hashtable from the static entry table and
calls theme_register("light", overrides), then frees the temporary
hashtable. It is called once from weechat_init right after theme_init.
Calling it twice is a no-op (the registry merges identical keys).
Default option values are NOT changed. Existing configs render exactly
as before; users opt in with "/theme apply light".
Add TEST(CoreTheme, BuiltinInit) covering:
- the "light" theme is absent before theme_builtin_init();
- it is present after, with >= 30 overrides;
- three spot-checked values match the source table;
- calling theme_builtin_init() a second time does not change the
override count.
Plugins contribute their own "light" overrides via weechat_theme_register
in subsequent commits.
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.
Add a single new entry point to the plugin API:
struct t_theme *weechat_theme_register (const char *name,
struct t_hashtable *overrides);
Plugins call this at init time to contribute their per-theme color (or
other themable) overrides for a built-in theme like "dark". The
overrides hashtable maps full option names ("irc.color.input_nick") to
their string values; the caller retains ownership and may free it
right after the call. Repeated calls with the same theme name merge
into the existing registry entry, so each plugin can declare its own
contributions independently of core and of other plugins.
Wiring:
- struct t_theme forward-declared in weechat-plugin.h alongside the
other opaque types.
- theme_register function pointer added to t_weechat_plugin.
- weechat_theme_register convenience macro added.
- plugin.c initializes the pointer to core's theme_register.
- WEECHAT_PLUGIN_API_VERSION bumped to 20260526-01.
This commit is plumbing only: the underlying theme_register function
already has unit-test coverage in tests/unit/core/test-core-theme.cpp
(TEST(CoreTheme, Register)), so no new tests are added here.
Add two completion items hooked alongside "layouts_names":
- "theme_themes_all": all theme names (built-ins from the registry
plus every *.theme file in <weechat_config_dir>/themes/, including
backup-*.theme). Used by tab-complete on /theme apply and
/theme info.
- "theme_themes_user": user theme files only (excludes built-ins
and backup-*.theme). Used by tab-complete on /theme save and
/theme delete, so users cannot accidentally try to overwrite a
built-in name or save a name colliding with the reserved backup
prefix.
Both callbacks share a small dir_exec_on_files-based helper to filter
the themes directory. The /theme command's completion template in
core-command.c is updated to reference these new items.
Add two complementary subcommands:
/theme save <name> [-full]: writes a user theme file at
${weechat_config_dir}/themes/<name>.theme containing the current
themable options. By default only options whose value differs from
their default (config_file_option_has_changed) are written, which
keeps the file small and focused. Pass "-full" to write every
themable option (matches the format used by automatic backups).
Name validation: refuses any name matching a built-in theme (those
are reserved for in-memory registrations) and any name starting
with "backup-" (reserved for /theme apply backups). Both checks
print an error and abort without writing.
/theme delete <name>: removes ${weechat_config_dir}/themes/<name>.theme
via unlink. Refuses to delete a name registered as a built-in
theme (a built-in has no file on disk to delete, even if the user
has a shadowing file of the same name they cannot remove it this
way; they can rename or delete it manually).
The full-snapshot writer used by /theme apply backups is refactored
into theme_write_file (name, description, diff_only). It is reused
by theme_make_backup (diff_only=0) and theme_save (diff_only inverted
from the user's -full flag).
Bug fix while at it: the writer was previously calling
config_file_option_value_to_string (ptr_option, 0, 1, 0); the third
and fourth arguments are "use_colors" and "use_delimiters", so the
call inserted GUI color escape codes into the file output and skipped
quoting strings. Corrected to (ptr_option, 0, 0, 1) so plain text
with proper string quoting is written; the change also fixes the
content of files produced by theme_make_backup in the previous commit.
Add a small INI-style parser for *.theme files and wire it into the
/theme command so user themes living in directory "themes" inside the
WeeChat configuration directory can be applied (and inspected) without
ever being cached.
Parser (theme_file_parse in core-theme.c) accepts two sections:
[info]
name = "..." \ shown by /theme info; ignored for apply
description = "..." |
date = "..." |
weechat = "..." /
(unknown keys are ignored with a warning)
[options]
full.option.name = "value"
Surrounding single or double quotes around a value are stripped (same
rule used by the regular config file reader). The parsed result is a
heap-allocated t_theme; the caller frees with theme_free.
Resolution rule in theme_apply: if the path
"${weechat_config_dir}/themes/<name>.theme" is readable it is parsed
and used (file shadows any built-in of the same name); otherwise the
built-in registry is consulted. The transient t_theme is freed before
the final refresh, so user themes have no steady-state memory
footprint regardless of how many .theme files have accumulated.
/theme list now also scans the themes directory and appends user
files to the listing (each marked "(file)"). backup-*.theme are
hidden by default; pass "-backups" to include them.
/theme info <name> works for both sources: file path is shown when the
information comes from disk; "built-in (in-memory)" otherwise.
Implement /theme apply <name> for themes currently in the in-memory
registry. The file-shadowing branch (read a .theme file from
${weechat_config_dir}/themes/ when no built-in matches) is added in
the next commit together with the parser.
Apply algorithm (theme_apply in core-theme.c):
- Look up the theme in the registry; abort with an error if unknown.
- If weechat.look.theme_backup is on and the target name does not
begin with "backup-", write a full snapshot of every themable
option to ${weechat_config_dir}/themes/backup-<timestamp>.theme
via theme_make_backup; abort the apply if the backup cannot be
written, so the user can always undo.
- Iterate the theme's overrides with theme_applying=1 so the
per-option config_change_color skips its gui refresh; for each
entry look up the option, refuse it if missing or non-themable
(warning to core buffer), otherwise call config_file_option_set.
- Perform a single gui_color_init_weechat + gui_window_ask_refresh
at the end.
- Persist the active label in weechat.look.theme and send signal
"theme_applied" with the name as data.
Add the new option weechat.look.theme_backup (boolean, default on)
which controls the backup-or-abort behaviour described above.
Wire the new /theme apply subcommand into core-command.c with the
existing /theme registration; update help text accordingly.
Add the /theme command with two read-only subcommands for now:
- /theme (or /theme list): list registered themes; the active theme
(matching weechat.look.theme) is marked with "->".
- /theme info <name>: show name, description, creation date, WeeChat
version and override count of a theme.
Both subcommands only consider themes present in the in-memory
registry (registered via core/plugins/scripts). User theme files on
disk are not yet handled: the file parser and transient file reads
land in a later commit together with /theme apply.
Add a new string option "weechat.look.theme" holding the name of the
last theme applied via the upcoming /theme command. It is set
automatically by /theme apply and persisted on disk for /theme info to
display after restart; it is NOT re-applied at startup (the user's
saved color values win to avoid clobbering manual post-apply tweaks).
Amend config_change_color so it skips the gui_color_init_weechat ()
and gui_window_ask_refresh (1) calls when theme_applying is set.
/theme apply will set this flag while iterating overrides so the N
individual option changes do not trigger N redundant screen refreshes;
the apply path then performs a single refresh at the end.
Introduce a new module (core-theme.{c,h}) holding the in-memory registry
of built-in themes used by the upcoming /theme command:
- struct t_theme stores name, description, date and weechat version
captured at registration time, plus a hashtable of overrides keyed by
full option name (file.section.option) -> value string.
- theme_register (name, overrides) creates a new theme or merges the
given overrides into an existing one (later calls override duplicate
keys); this is the API plugins and scripts will use to contribute
per-theme color values.
- theme_search and theme_list provide lookup and ordered enumeration.
- theme_init / theme_end are called from weechat_init / weechat_end.
The theme_applying flag is declared here but not yet consumed (it will
gate config_change_color in the next commit to avoid N redundant
window refreshes during /theme apply).
User theme files are not handled by this module: they are read
transiently inside /theme apply (a later commit) and never cached.
Extend the "t:" filter so the special value "themable" matches every
option whose new themable flag is set, regardless of type (color,
string, integer, boolean, enum). This makes the flag interactively
discoverable in the fset buffer and is the natural way to inspect the
surface area that an upcoming /theme command will be allowed to touch.
The themable flag of an option is now mirrored on struct t_fset_option,
exposed via hdata ("themable", integer) and infolist ("themable",
integer), and printed in the log.
Add an "int themable" field on struct t_config_option. The flag is set
automatically for every CONFIG_OPTION_TYPE_COLOR option, and may be set
explicitly on any other type by suffixing the type argument with
"|themable" in the call to config_file_new_option (e.g. "string|themable"
for a string option whose value contains "${color:...}" references).
Opt in the relevant string options in core (buffer_time_format,
day_change_message_*, item_time_format, nick_color_force, prefix_*,
chat_nick_colors, eval_syntax_colors, color palette aliases) and in the
buflist, fset, irc, relay plugins.
The flag is exposed via hdata, infolist, and print_log so scripts and
/debug can read it. This is the foundation for an upcoming /theme
command that will only be allowed to modify themable options.
A relay client could send data with no end-of-line (an unterminated method
or header line) and dribble its payload, making WeeChat accumulate it in the
partial message buffer that grew without limit, until all memory was
exhausted. This path is reachable before authentication during websocket
initialization with the "weechat" and "irc" protocols.
The accumulated partial message is now bounded by
RELAY_HTTP_PARTIAL_MESSAGE_MAX_LENGTH: once the limit is reached, the extra
data is ignored.
A relay client could announce a huge websocket frame (or HTTP body via
"Content-Length") and dribble its payload, making WeeChat accumulate it
in a buffer that grew without limit, until all memory was exhausted. The
websocket frame path is reachable before authentication with the
"weechat" and "irc" protocols.
The announced websocket frame length and HTTP "Content-Length" are now
bounded by WEBSOCKET_FRAME_MAX_LENGTH and RELAY_HTTP_BODY_MAX_LENGTH: an
oversized websocket frame closes the connection, and an oversized body is
rejected.
A malicious or compromised IRC server could send data with no end-of-line
(or a flood of "005" messages), making WeeChat accumulate it in a buffer
that grew without limit, until all memory was exhausted.
The unterminated received message and the accumulated "005" (ISUPPORT)
data are now bounded by IRC_SERVER_RECV_MSG_MAX_LENGTH and
IRC_SERVER_ISUPPORT_MAX_LENGTH: extra data is ignored once the limit is
reached.
weecrypto_totp_validate compared the generated and client-supplied OTPs
with strcmp and broke out of the time-window loop on the first match.
Both choices leaked information via response timing: strcmp leaked the
expected OTP digit-by-digit (shrinking the brute-force search from
~10^digits to a handful of guesses within the 30-second window), and
the early break leaked which window offset matched.
Compare in constant time with string_memcmp_constant_time and always
iterate the full window, OR-ing the result into otp_ok without an
early exit.
This affects both relay protocols (which call totp_validate via the
public info hook) and any other caller of the info hook.
The IRC relay protocol's PASS handler compared the server password with
the client-supplied value using strcmp, leaking the password byte-by-byte
via response timing. This is the same class of bug fixed for the api and
weechat protocols, on a separate code path that did not go through
relay_auth_check_password_plain.
Extract the HMAC-then-constant-time-compare logic from
relay_auth_check_password_plain into relay_auth_password_equals, then
use it in both the plain-auth wrapper and the IRC PASS handler.
The relay authentication used non-constant-time comparisons (strcasecmp,
strcmp) to verify password hashes and plaintext passwords, allowing an
attacker to derive the expected hash byte-by-byte from response timing
and then authenticate without knowing the password.
- SHA/PBKDF2 hex hash comparisons: normalize the client-supplied hash to
uppercase and compare in constant time over the fixed expected length.
- Plaintext password comparison: HMAC-SHA256 both passwords with a fresh
per-call random key and compare the fixed-size MACs in constant time,
hiding both per-byte timing and the password length.
Add string_memcmp_constant_time helper in core, exposed via the plugin
API. Bump WEECHAT_PLUGIN_API_VERSION accordingly.
An authenticated relay client using the permessage-deflate websocket
extension could send a small compressed frame that decompresses to an
unbounded amount of data, exhausting all memory and crashing WeeChat.
The output buffer in relay_websocket_inflate is now capped to
WEBSOCKET_INFLATE_MAX_SIZE: frames decompressing beyond this limit are
rejected and the connection is closed.
If pygmentize is not found, the build now emits a CMake warning and
proceeds with an empty dark theme stylesheet rather than aborting.
A non-zero exit from pygmentize is also downgraded from SEND_ERROR to
WARNING for the same reason. This restores the pre-existing behavior
where the documentation could be built without any pygments tooling
installed (Asciidoctor then renders code blocks as plain text).
Syntax highlighting now follows the user's `prefers-color-scheme`:
- Light theme uses the pygments `default` style, embedded by Asciidoctor as before.
- Dark theme uses the pygments `monokai` style, generated at CMake
configure time via `pygmentize` and injected into the docinfo through a
`@PYGMENTS_DARK_CSS@` placeholder, scoped under
`@media (prefers-color-scheme: dark)`.
To support template substitution, `doc/docinfo.html` is renamed to
`docinfo.html.in` and produced into the build directory via
`configure_file`; all HTML targets now depend on the generated docinfo
and the `docinfodir` attribute points to the binary dir.
Code blocks also gain a subtle 3D bevel:
- `pre` borders use theme-specific bevel colors (`--pre-bevel-light` on
top/left, `--pre-bevel-dark` on bottom/right) for a raised look in both
themes.
- A shared `--pre-bevel-bg` surface color is applied to literalblock,
listingblock and `pre.pygments`, so all code blocks sit on the same
background regardless of the pygments style.
- `pre { line-height: 1.25 }` is forced to keep line spacing consistent
between light (Asciidoctor base `1.45`) and dark (pygments `125%`).
`python3-pygments` is added to the documented build dependencies (the
`pygmentize` binary it provides is required at configure time).
Since v4.8.0 and commit d0298b4738, toggling
filters with `/filter toggle` displays a message on core buffer.
This is OK when running the command manually, but not when pressing the key
alt+"=".
Bump the requirement to v1.4.0, which means we can remove all the ifdef
guards.
It was released over 6 years ago, with latest release being 1.5.7.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 1.4.4 and 1.4.8 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In commit 9a9a262ea1 we moved from
pkg-config to find_package() to work around a deficiency in the pkgsrc
package manager, which does not ship pkg-config files as intended by
CPython.
Modern CMake discourages use of "FOO_LIBRARIES" in all cases, when
imported "interface" libraries can and should be used instead. The meson
equivalent is `dependency()` versus `cc.find_library()`, so this is
certainly a general trend among modern build systems.
An imported interface target, such as the previous PkgConfig::PYTHON,
carries with it the various internal properties such as DEFINITIONS,
INCLUDE_DIRS, or LIBRARIES, and batch applies them. It also avoids
leaking across cmake 2.x style whole-directory scopes.
Use the documented cmake imported interface target for embedding Python
and avoid `add_definitions(${Python_DEFINITIONS})` and similar. As a
bonus, it's also shorter and more concise.
Fixes: 9a9a262ea1
Fixes: https://github.com/weechat/weechat/pull/2251
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
In commit 9a9a262ea1 we moved from
pkg-config to find_package() to work around a deficiency in the pkgsrc
package manager, which does not ship pkg-config files as intended by
CPython. In the process, Gentoo and other platforms that, unlike pkgsrc,
publicly support multiple versions of python installed in parallel, had
python version selection broken. Consequently, weechat linked to the
wrong python, which happened to be installed in build chroots but was
not the versioned python package that the weechat package listed as a
dependency. Attempting to install weechat then broke on some systems
(which installed one version of python as a dependency but actually
linked to a totally different one).
This happens due to a design bug in upstream CMake. It is never
conceptually reasonable to use
```
find_package(Python COMPONENTS ...)
```
and omit the "Interpreter" component; if you do, CMake will ignore its
own documentation on how to control the build to use a specific python,
and choose one randomly (== "latest version available"). If, and only
if, the Interpreter component is checked, the development headers /
libraries for python will be guaranteed consistent with the documented
lookup variables from FindPython.cmake's documentation.
Bug: https://bugs.gentoo.org/968814
Fixes: 9a9a262ea1
Fixes: https://github.com/weechat/weechat/pull/2251
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Move the requirement checks within the respective plugin cmakefile.
Use REQUIRED instead of the manual FOUND check and error handling.
Note: the tcl check was only moved, since using REQUIRED explodes in
CI.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the requirement checking and the dummy test where they are used.
Use REQUIRED instead of the manual FOUND check and error handling.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
With CMP0083 introduced with cmake 3.14, as we set the variable
CMAKE_POSITION_INDEPENDENT_CODE we can rely on the build system to do
the correct thing, across all the targets.
Since we require 3.18 (or 3.16 in the patched Debian/Ubuntu version),
which sets the policy to NEW we're all set.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Whenever cmake_minimum_required() is used, all the policies available in
the specified version are toggled to NEW. Thus we no longer need to
manually change them.
The highest policy - CMP0017 - has been around circa cmake 2.8.4, while
we require 3.x.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The token has been available since cmake 3.0 (at least), so might as
well use it instead of our ad-hoc check.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the respective include_directories() stansas to the top-level
cmakefile. While this technically adds them to targets where they are
not needed, there is no harm is having them.
This maskes the find_dependency/use_includes/use_libs more consistent
across the board and helps it stand out where it's forgotten. Fixes for
which will be coming at a later date.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Avoid creating/appending variables and effectively deviating from the
style used across the project.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The tcl ones has not been required for over a decade since commit
ffdba5b24 ("Remove check of Tcl_CreateNamespace in cmake build (not used
any more) (bug #27119)").
While the top-level one, with the EXTRA_LIBS reshuffle/consolidation a
few commits ago.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Since commit e98a32373 ("core: check if res_init requires linking with
libresolv") we detect if/when we should be linking against libresolv.
The detection seems a bit clunky (to me), although it's better to keep
things consolidated/consistent across tree. Swap the Darwin checks with
the new token LIBRESOLV_HAS_RES_INIT.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Note that final handling varies a bit, namely:
- OpenBSD/intl should be handled via the existing cmake/FindGettext.cmake
- Darwin/resolv should not be needed since commit e98a32373 ("core: check
if res_init requires linking with libresolv")
- the backtrace/execinfo handling has been consolidated and moved
In the unlikely case of unwanted over-linking, the platforms can add
`-Wl,--as-needed` to their linker flags. Something which is strongly
encouraged and has been the default across multiple (linux) distros for
years.
Alternatively, if move quirks are needed they should be handled in a
single place.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
This change technically adds an extra link for the unit tests, which
seemingly was omitted by mistake. Alternatively, the extra over-linking
won't be an issue in practise.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In a handful of places we explicitly use add_dependencies() where the
exact same libraries are also (implicitly) added as dependencies via
target_link_libraries().
Remove the folder, which helps us remove some duplication with follow-up
patches.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
There is an issue with some IRC servers that may send a JOIN with self nick
once already on the channel, this results in a clear of the nicklist on the
second JOIN received.
This fix silently ignores the second self JOIN if the channel is already
joined (with at least one nick).
The regression was introduced by commit
1b669cd13c, which allowed a server name with
upper case but rejected a name or alias with upper case.
This commit fixed the creation of the option when the server name is not given,
so this command works again:
/set irc.msgbuffer.whois current
The command has now the same output as `/filter enable` or `/filter disable`:
/filter toggle => "Message filtering disabled"
/filter toggle => "Message filtering enabled"
Now the following command is OK without warning:
/set irc.msgbuffer.TEST.notice current
And the following command returns an error instead of a warning (that means the
option is NOT created):
/set irc.msgbuffer.TEST.NOTICE current
The function `util_parse_time` is now first used to parse the date/time,
allowing to auto-detect the format (not based on the option
logger.file.time_format).
If the parsing fails, then we fallback on the call to `strptime`, using the
format in option logger.file.time_format (legacy behavior).
This allows to change the option logger.file.time_format without impact on the
display of the backlog.
Bump the requirement to v2, which means we can remove the
HAVE_ENCHANT_GET_VERSION workaround.
It was released over 8 years ago, with 8 new feature releases since
then and dozens of bugfix releases throughout.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 2.2.8 and 2.2.15 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v5.3, which means we can remove all the ifdef
guards.
It was released over 10 years ago, with 2 new feature releases since
then and half a dozen of bugfix releases in the 5.3 branch.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 5.3.3 and 5.4.2 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v1.8.0, which means we can remove ~70% of the
ifdef guard.
It was released over 8 years ago, with 3 new feature releases since
then and dozen of bugfix releases in the 1.8 branch.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 1.8.5 and 1.8.7 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v3.6.3, which means we can remove the final
ifdef guard and all the builds have TLS 1.3 support.
It was released over 7 years ago, with 2 new feature releases since
then and dozen of bugfix releases in the 3.6 branch.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 3.6.13 and 3.7.1 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v7.68.0, which means we can remove ~70% of the
ifdef guards. It was released over 5 years ago, with 30+ new curl
releases since then and dozens of CVEs fixed.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 7.68.0 and 7.74.0 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This fixes this warning with clang:
src/core/core-url.c:1017:5: warning: call to '_curl_easy_setopt_err_long' declared with 'warning' attribute: curl_easy_setopt expects a long argument [-Wattribute-warning]
1017 | curl_easy_setopt (curl, CURLOPT_PROXYPORT,
| ^
/usr/include/x86_64-linux-gnu/curl/typecheck-gcc.h:50:15: note: expanded from macro 'curl_easy_setopt'
50 | _curl_easy_setopt_err_long(); \
| ^
When invalid data is received (not an HTTP request), client->http_req->method
is NULL, so we have to check it's not NULL before comparing it to the supported
methods.
This fixes a regression introduced in commit
93ec10b563.
This fixes the API probe made by schemathesis, so it detects immediately that
such NULL byte is not allowed by WeeChat, instead of timing out after 10
seconds:
✅ API capabilities:
Supports NULL byte in headers: ✘
Previous behavior was to reverse the partial completion, which was confusing
when option like weechat.completion.partial_completion_command_arg was enabled
as well.
This allows asciidoctor to display important messages, for example invalid
references like this one:
asciidoctor: INFO: possible invalid reference: compile_with_cmake
This reverts commit e64ab3c675.
This was causing incorrect conversion of strings "0x..." to pointers on systems
like Solaris/illumos.
And as a side effect, buffers were sometimes empty in weechat relay clients
like glowing-bear.
Now the function utf8_next_char with an empty string returns NULL instead of
the next char, which is most of the time after an allocated buffer.
And the function utf8_char_size with an empty string now returns 0 instead of
1.
This indirectly fixes a buffer overflow in function eval_string_range_chars
when the input string is empty (for example when doing `/eval -n ${chars:}`).
This commit introduces fuzz testing, for now on core functions, with 4 new
targets that are built on demand with CMake option `ENABLE_FUZZ` (build of
these tests is disabled by default):
- weechat_core_calc_fuzzer
- weechat_core_crypto_fuzzer
- weechat_core_string_fuzzer
- weechat_core_utf8_fuzzer
Building WeeChat 4.6.0 on OpenBSD failed with the following error.
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/weechat-perl.c:356:13: error: expected ')'
> function) < 0)
> ^
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/weechat-perl.c:352:9: note: to match this '('
> if (weechat_asprintf (
> ^
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/../weechat-plugin.h:1312:31: note: expanded from macro 'weechat_asprintf'
> (weechat_plugin->asprintf)(__result, __fmt, ##__argz)
On further inspection, the line in question was recently altered in
099e11d7b8, where a comma was forgotten in the
else branch of the MULTIPLICITY ifdef.
After adding the comma, WeeChat builds as usual.
At the moment, building WeeChat triggers several thousand -Wstrict-prototypes
diagnostics. This is due to its source code using an empty argument list for
functions and function pointers that take no arguments, instead of explicitly
declaring that they take no arguments by using a void list.
This commit replaces all empty argument lists with a void list.
Note that Ruby's headers also suffer the same problem, which WeeChat can't
do anything to fix. Thus, building WeeChat with the Ruby plugin enabled
will still issue approximately 30 such diagnostics.
This fixes a bug when writing configuration files with a wrong locale: now
UTF-8 is kept and written in files instead of string converted using a wrong
charset.
New options are added to configure the chars displayed for spaces and
tabulations:
- weechat.look.whitespace_char: char for spaces
- weechat.look.tab_whitespace_char: first char for tabulations
New default key:
- Alt+Ctrl+l (L): toggle execution of commands: remote/local
New options:
- relay.api.remote_input_cmd_local: text displayed for command executed locally
- relay.api.remote_input_cmd_remote: text displayed for command executed on the
remote WeeChat
src/gui/curses/gui-curses-main.c: In function ‘gui_main_loop’:
src/gui/curses/gui-curses-main.c:399:33: error: passing argument 2 of ‘signal_catch’ from incompatible pointer type [-Wincompatible-pointer-types]
399 | signal_catch (SIGWINCH, &gui_main_signal_sigwinch);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void (*)(void)
In file included from src/gui/curses/gui-curses-main.c:38:
src/gui/curses/../../core/core-signal.h:33:46: note: expected ‘void (*)(int)’ but argument is of type ‘void (*)(void)’
33 | extern void signal_catch (int signum, void (*handler)(int));
| ~~~~~~~^~~~~~~~~~~~~
This follows the recommendation from Pythons documentation for
PyModule_GetDict where it says:
It is recommended extensions use other PyModule_* and PyObject_*
functions rather than directly manipulate a module’s __dict__.
This value determines the size of the per-module memory area. Setting
this value to -1 as it was before this change means that the module has
global state and therefore does not support subinterpreters.
However, subinterpreters are used to run the Python scripts, so the
weechat module has to support subinterpreters. Therefore we should set
this value to 0 as no per-module memory is required.
This seems to fix the crash reported in #2046 without the need for the
workaround added in commit 85c7494dc (it does for me when testing with
Python 3.12.0 at least).
This change came up as a suggestion in cpython's issue tracker where it
was pointed out that using modules with m_size set to -1 is not
supported in subinterpreters. See these two comments:
https://github.com/python/cpython/issues/116510#issuecomment-2377915771https://github.com/python/cpython/issues/116510#issuecomment-2389485369
It's not completely clear to me what is required for a module to support
subinterpreters and re-initialization (which is required for setting
m_size to 0), but https://peps.pythondiscord.com/pep-0489/ says:
A simple rule of thumb is: Do not define any static data, except
built-in types with no mutable or user-settable class attributes.
The only static data we define is of type int and str, so I think it
should be fine.
This fixes the following CMake warning:
CMake Warning (dev) at src/gui/curses/normal/CMakeLists.txt:73 (add_custom_command):
Exactly one of PRE_BUILD, PRE_LINK, or POST_BUILD must be given. Assuming
POST_BUILD to preserve backward compatibility.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
This fixes a crash which would happen if you scrolled the script buffer
and then did a search which got fewer search results than the index of
the selected line before the search. E.g. press page down to go to the
second page and then search for `test`.
It turns out that Debian has reverted the commit in Perl that broke the
locale in their 5.38 branch, so it did not have the issue. However, the
workaround we added to fix the locale apparently makes the version
Debian/Ubuntu has crash on perl_destruct. I'm not sure why it makes it
crash, but since it doesn't crash on newer Perl versions, I'm assuming
that it's another bug with the locale handling in that Perl version.
To avoid the crash, make sure to only set the locale if we detect that
it has been broken by Perl. We do this by checking if the value returned
by wcwidth (160) (the first non-ascii printable character) has changed.
If this value is not the same after the call to perl_construct, the
locale has been broken.
I moved the call to Perl_setlocale to right after perl_construct, as the
call to perl_construct is what breaks the locale.
Apparently the issue with the locale being reset with Perl 5.38 can
cause a crash when unloading the scripts on some systems (at least
Ubuntu 24.04). There was a workaround added in commit f4b9cad72, but it
doesn't work to avoid the crash. However if we set LC_ALL instead of
LC_CTYPE the crash doesn't occur.
Fixes#2187
If a request repeats the same header name multiple times, merge the
header values into a comma separated string. Previously, only the last
header specified would be used.
For header fields that are defined as a comma-separated list, a client
may choose to send it as multiple headers instead of one header with
comma-separated values. The specification says that these are
equivalent, so we can therefore join the headers into a comma-separated
string.
This is specified at https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2
which says:
A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
The API for connecting to WebSockets in browsers unfortunately doesn't
support setting any Authorization header. This means that before this
commit it was impossible to connect to the API relay from a web browser.
The only thing that can be set apart from the URL is the
Sec-WebSocket-Protocol header. Therefore this allows you to send the
auth token in this header.
This is a weird way to send auth, but it seems to be the best one that
makes it possible for browsers to connect. Kubernetes also does it this
way: https://github.com/kubernetes/kubernetes/pull/47740
Here is a post describing the different ways to make it possible for a
browser to authenticate against a websocket connection, and it also
recommends doing it this way:
https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api/77060459#77060459
Note that when this header is used to pass auth, the client also needs
to specify the `api.weechat` sub protocol. This is because the client
and server have to agree on a sub protocol when this header is
specified, and in order to not send the fake protocol used for auth back
to the client, we require specifying the protocol `api.weechat`, which
the server then returns to the client. This is only necessary when the
Sec-WebSocket-Protocol header is used. If the Authorization header is
used for auth as before, nothing changes.
Detail of changes:
- the save of upgrade files in plugins is now done as soon as the "upgrade"
signal is received, and not when the plugin is unloaded (it was too late to
detect any problem and prevent the upgrade to happen)
- if the write of an upgrade file fails, the signal callback in plugin now
returns WEECHAT_RC_ERROR and WeeChat checks this code to stop the upgrade as
soon as this return code is received
- a new flag is added in plugin structure: unload_with_upgrade, it is set to 1
before unloading all plugins when upgrade will happen (all *.upgrade files
are then already successfully written).
For now the only supported flag is:
- "stop_on_error": stop execution of callbacks immediately after an
error (ie return code of callback is WEECHAT_RC_ERROR) and return this code
(by default execute all callbacks and return the last return code, or return
WEECHAT_RC_EAT immediately if a callback returns this)
Example:
hook_signal_send("[flags:stop_on_error]my_signal", WEECHAT_HOOK_SIGNAL_STRING, "test");
A performance issue was happening when buffers are moved to another position
and when the hotlist contains a lot of buffers: each time a signal
"buffer_moved" is sent, the hotlist is sorted again.
This fix delays the resort of hotlist after all the moves are done using a
timer with a very small delay (one millisecond).
Since WeeChat 4.0.0, the actions are now case sensitive and must be typed as
lower case.
This fixes the help line displayed on top of relay and xfer buffers: letters
for actions are now displayed with lower case instead of upper case.
Bump the requirement to v3.3.0 as available in Ubuntu 16.04 (3.4.10) and
Debian 10 (3.6.7). It was released around 10 years ago and any remotely
supported distribution has newer version.
As result, we can remove hundred+ lines of #ifdef spaghetti code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Remove the local cmake file and associated hacks used to manage GnuTLS.
This gives us less build-system glue code and makes it easier to enforce
a minimum version for GnuTLS.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v7.47.0 as available in Ubuntu 16.04 (7.47.0)
and Debian 10 (7.64.0). It was released around 9 years ago and any
remotely supported distribution has newer version.
As result we can adjust the tools/check_curl_symbols.py script to omit
the ~70% of the guards and simplify the code base.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The cURL project has provided a pkg-config file for well over a decade
now. Just use that instead of the cmake one, since the latter also
checks for misc curl components, unusual library names (libcurl_imp)
which is not something we need.
In addition, this will make enforcing minimum version much easier.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The curl option handling seems to be non-functional since it suffers
from two distinct issues. The regular expression tries to match options
that we're not interested in and the symbol name is lacking the proper
prefix.
Adjust to match only on what we need and construct the name
appropriately... Fix the issues flagged by the updated script.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
When the environment variable `RETRY_BUILD` is set to `1`, the file
`debian/rules` is patched to run `dh_auto_build` multiple times, until the
build succeeds.
This is a workaround for an issue with the build in an arm64 chroot, where the
compiler randomly segfaults.
The gcrypt, gnutls, libcurl and zlib are core libraries/components that
we always build against. Remove the #ifdef checks - the symbols must be
available at build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Seemingly unused for ~12 years, since commit a99d13601 ("core: add new
plugin "script" (scripts manager, replacing scripts weeget.py and
script.pl)")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
With the circular dependency resolved, we no longer need this variable.
Add the respective objects directly, in the same order as seen in the
tests.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In order to resolve the circular dependency, we need to annotate the
respective static libraries as "object" libraries.
This requires cmake 3.12, where Debian 10 (old old stable) and Ubuntu
20.04 have 3.13 and 3.16 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
To ease the initial hurdle of using the proper formatting across files,
introduce a simple .editorconfig file.
Nearly every common editor supports it OOTB these days, including the
GitHub and GitLab web editors.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Before parsing IRC messages, they were almost all changed to convert IRC color
codes to WeeChat color codes, which caused some bugs when storing data like
account and real names (stored with WeeChat color codes instead of IRC colors).
Now the messages are parsed as-is, then the colors are converted only when
strings are displayed in a buffer by `weechat_printf()`.
This should definitely fix the crash with Python 3.12, even when scripts are
auto-loaded (the previous fix was working only when the scripts are loaded
manually).
Python 3.12 has a bug where it crashes when you unload all the
interpreters unless you make sure to unload the first interpreter you
loaded last. For some reason, loading the eval interpreter before any
scripts also seems to prevent the issue, even if the eval interpreter is
unloaded before the other interpreters.
So this just evals an empty string at the end of initing the Python
plugin if the Python version is 3.12, to make sure the eval interpreter
is loaded first.
Fixes#2046
Syntax is one of:
- `hdata_count:name[list]`: uses a hdata name and list
- `hdata_count:name[pointer]`: uses a hdata name and pointer (count starts at
this pointer)
This fixes a test failure when the test changing the option is executed before
this one:
…/tests/unit/plugins/relay/api/test-relay-api-protocol.cpp:799: error: Failure in TEST(RelayApiProtocolWithClient, RecvJson)
expected <HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: Z5uTZwvwYNDm9w4HFGk26ijp/p0=
>
but was <HTTP/1.1 403 Forbidden
Content-Length: 0
>
difference starts at position 9 at: < HTTP/1.1 403 Forbid>
Use pkg-config to detect libgcrypt, since command `libgcrypt-config` is not
available any more.
Remove patches for Debian/Raspbian Buster and Ubuntu Bionic: detection of
libgcrypt don't work any more with version 1.8.4 on Debian Buster and 1.8.1 on
Ubuntu Bionic (both versions don't provide the file `libgcrypt.pc`).
1: error: Failure in TEST(RelayApiMsg, HotlistToJson)
1: expected <2024-05-26T10:29:37.716512Z>
1: but was <2024-05-26T10:29:37.000000Z>
1: difference starts at position 20 at: <T10:29:37.000000Z >
This fixes the following warning emitted by gcc:
…/relay-http.c:1207:32: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 64 [-Wformat-truncation=]
1207 | "%s[%d bytes data]",
| ^~
1208 | str_header,
| ~~~~~~~~~~
…/relay-http.c:1207:31: note: directive argument in the range [1, 2147483647]
1207 | "%s[%d bytes data]",
| ^~~~~~~~~~~~~~~~~~~
…/relay-http.c:1206:21: note: ‘snprintf’ output between 15 and 1047 bytes into a destination of size 64
1206 | snprintf (raw_message, length_raw,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1207 | "%s[%d bytes data]",
| ~~~~~~~~~~~~~~~~~~~~
1208 | str_header,
| ~~~~~~~~~~~
1209 | *ptr_body_size);
| ~~~~~~~~~~~~~~~
Changes are now grouped by category:
- `Changed`: changes in existing features
- `Added`: new features
- `Removed`: removed features
- `Fixed`: bug fixed
Changes are also sorted by importance: breaking changes and most important
changes first in each category.
Link to release notes is mentioned in each release for which manual actions are
required upon upgrade.
This prevents unexpected updates of input on remote buffer whenever something
changes in the buffer, like a local variable, but with the same unchanged
input.
New fields returned:
- "input" (string): content of input
- "input_position" (integer): position in input (starts at 0)
- "input_multiline" (boolean): true if the buffer allows multiline input
This parameter is the number of lines to return for buffers with free content.
Its default value is `0` if "lines" is set to `0`, otherwise all buffer lines
are returned.
weechat.h already handles libintl.h and defining suitable macros.
Including it again does nothing other than emit a compile warning when
compiling without NLS:
In file included from /var/tmp/portage/net-irc/weechat-9999/work/weechat-9999/src/core/core-doc.c:35:
/var/tmp/portage/net-irc/weechat-9999/work/weechat-9999/src/core/weechat.h:49: warning: "gettext" redefined
49 | #define gettext(string) (string)
|
In file included from /var/tmp/portage/net-irc/weechat-9999/work/weechat-9999/src/core/core-doc.c:30:
/usr/include/libintl.h:109: note: this is the location of the previous definition
109 | # define gettext(msgid) dgettext (NULL, msgid)
If buffer->input_get_any_user_data is set to 1, any command executed via a
buffer local key is considered as user input and then sent to the buffer
callback, instead of being executed directly.
This is used on relay remote buffers, to execute the command on the remote
instead of locally.
When 4 directories are received, the state directory is initialized with the
data directory.
This fixes the following error on `/upgrade`:
Error: wrong number of paths for home directories (expected: 1 or 5, received: 4)
The id is a "long long" variable with the current time (microseconds
precision).
It is guaranteed to be unique for all groups and nicks inside the buffer, and
the same number is never used again in the same buffer, during the lifetime of
the process.
It persists and is unchanged after `/upgrade`.
Connection to remote:
- handshake: offer support for all supported hash algorithms
- network connect with a socket
- upgrade to websocket and authenticate with remote (password/TOTP)
- check websocket response
- get list of buffers (not used yet)
Note: connection to remote with TLS or a proxy is not yet supported.
When a CTCP request is received on a channel, WeeChat replies to the nick and
it is now displayed in the server buffer instead of the channel, as the target
is a nick and not a channel.
Restore original signals caught: "buffer_moved" and "buffer_closed", and the
signal "buffer_localvar_*" is added so that any local variable
added/changed/removed triggers a re-sort of hotlist.
When you run /input search_stop it should scroll to the scroll position
the buffer was at before starting the search, rather than to the bottom
of the buffer.
Fixes a regression introduced in commit b83b428c5cFixes#2093
The id is a "long long" variable with the current time (microseconds
precision).
It is guaranteed to be unique for all buffers, and the same number is never
used again, during the lifetime of the process.
It persists and is unchanged after `/upgrade`.
Some parameters of command `/script` were renamed in commit
85b5bacfe3 but the default mouse keys were not
changed and still using the old parameters names.
The server option "autojoin_delay" adds a delay before autojoin.
The server option "command_delay" is now used to add a delay before the
execution of the command.
On upgrade from an old version, the option "command_delay" is copied to
"autojoin_delay" (in old versions, "command_delay" was applied after the
execution of command and before the autojoin).
When the message sends inconsistent max lengths in message 005, the split of
self message fails and causes a display issue: the channel name is displayed
with the message:
nick | #channel :this is a test
instead of:
nick | this is a test
This prevents a crash in some scripts that could use options after they are
freed, with the call to hook config callback that has been enabled by commit
2260214797.
This fixes a refresh issue on the fset buffer when a plugin is unloaded: now
the options displayed that are freed are properly removed from the fset buffer.
When php imagick is installed and when WeeChat is compiled with gcc, there's a
crash when the php plugin is loaded. Newer versions of gcc should fix the
issue, but as in CI we can't easily use them, uninstalling imagick avoids the
crash.
A mask with wildcards is now allowed in the following commands:
- `/trigger enable`
- `/trigger disable`
- `/trigger toggle`
- `/trigger restart`
- `/trigger del`
- `/trigger restore`
Errors from hook_url should be handled by the caller, so don't print
them to the core buffer by default. Only print them when
weechat_debug_core is enabled. This was already the behavior for the
timeout error.
When hook_url fails, add an error_code field in the output in addition
to the error field. This is so the caller can get which error happened
programatically, without having to parse the (possibly translated) error
string.
It uses the same error codes as the return_code in hook_process, and in
addition adds 5 for an error from pthread_create and 6 for a timeout
error. If the error is from pthread_create, an additional field
`error_code_pthread` with the error code from pthread_create is added.
If the error is from curl, an additional field `error_code_curl` with
the error code from curl is added.
The clean of processes with waitpid() is now delayed after the kill(), so that
there are no more zombies.
In addition, this can be done manually if needed with `/sys waitpid`.
This commit also includes support for passive DCC RESUME.
There was also a potential segfault with calling `atoi(pos_token)` when `pos_token` is NULL, so `token` is set to be stored as a string. Although it is an integer, we don't need to store it as such. That's really more of an implementation detail.
This makes it easier to handle the optional "token" argument at the (right) end, which will be necessary to support passive DCC.
Incidentally, this is RtL parsing order is the reason why you'd get a cryptic "0" address error when attempting to do passive DCC: the "token" argument gets misinterpreted as the "size" argument. Every argument "shifts" over by one, leaving an address (port) of "0".
This makes possible to disable a key hiding another (because shorter than the
other, and beginning with the same key).
For example if key "meta-a" is set to an empty command, it would not hide any
more the key "meta-a,1" which has a non-empty command.
The | syntax for unions is only supported in Python 3.10 and later.
Since Python 3.8 and 3.9 are still supported upstream for a while and we
had a user reporting on IRC that they couldn't use the stub file since
they are using 3.8, change to the old syntax for unions to support this.
There aren't really any drawbacks of this. It's just a bit more verbose,
and a typing import is necessary, but neither of those really matters in
a generated stub file.
This allows the user to bind or unbind keys by setting options
"weechat.buffer.irc.list_xxx.key_bind_*" and
"weechat.buffer.irc.list_xxx.key_unbind_*".
This allows the user to bind or unbind keys by setting options
"weechat.buffer.script.scripts.key_bind_*" and
"weechat.buffer.script.scripts.key_unbind_*".
Reintroduce infos "irc_nick_color" and "irc_nick_color_name" (that were
marked deprecated since version 1.5).
A server name is added in the two infos and is optional, for backward
compatibility.
This removes the following CMake warning:
CMake Deprecation Warning at CMakeLists.txt:22 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
This happens when server option autojoin_dynamic is on and option
irc.look.buffer_switch_autojoin is off.
Regression was introduced in version 4.0.0 by commit
1c3b871204.
The options `weechat.custom_bar_item.xxx.*` are now properly renamed to the new
item name.
This fixes a save issue (item saved with old name in config) and a crash if a
new item is created with the old name.
The type "enum" replaces type "integer" when used with string values.
For compatibility, any option created with type "integer" and string values is
automatically created to "enum" on creation, with no error.
The command is now executed on the buffer where it is received instead of the
current buffer (in most cases this is the same buffer, but could be different
sometimes).
If you press an incomplete key sequence, previously WeeChat would send
the key_pressed signal again for the same keys on the next key.
E.g. if you press escape and then 1, previously you would get the
key_pressed signal with signal_data `\x01[` when you pressed escape, and
then key_pressed with `\x01[` again when you pressed 1 (plus key_pressed
with `1` for the 1 key). So two signals for the escape key, even though
it was only pressed once.
With this patch, you only get one signal for each key press. So one with
`\x01[` when you press escape and then one with `1` when you press 1.
Version 4.0.0 (specifically commit 1f5c791c3) changed the key handling
so key_combo_* signals were sent for each character in a sequence,
rather than just when the sequence is finished. This broke parts of the
vimode.py script.
E.g. for the up arrow, 3.8 sends key_combo_default signal once with the
signal_data `\x01[[A`, while 4.0.0 sends it three times with the
signal_data `\x01[`, `\x01[[` and `\x01[[A`.
With this patch, the previous behavior is brought back. There is one
small change though. In 3.8 if you press escape one or two times it
doesn't send key_combo_default, but if you press it three or more times
it sends it for each escape press. With this patch, it's never sent for
plain escape presses, only when the sequence is finished with some other
key.
This is intentional, as getting key_combo_default for escape presses
doesn't make sense since it's not a finished combo, and the behavior of
3.8 where you got it after three or more key presses was most likely
unintentional as it just happened because it didn't match any key
bindings anymore (there are key bindings starting with one or two escape
characters, but not more).
This fixes a bug where if you had multiple lines in the input and
pressed ctrl-w when the cursor was after the first word of any line but
the first, it would delete both the word before the cursor and the last
word on the preceding line.
Commands 716/717 are returned if the target user has mode +g, they look like
this:
:server 716 my_nick bob :is in +g mode and must manually allow you to message them. Your message was discarded.
:server 717 my_nick bob :has been informed that you messaged them.
These variables are the same as "_chat_bol" and "_chat_eol" except that they
stop at the beginning of the focused line (not the whole message displayed, in
case message has multiple lines separated by "\n").
Regression was indirectly caused by commit
d18f68e497 in core that allows to display all
control chars in buffers.
But the fix is in exec plugin: end of line in command output can now be "\r\n"
in addition to a single "\n".
This allows you to use escape characters if you start the fifo command
with \ instead of *, in the same way as the escape_commands option in
the relay protocol. This allows you to send commands consisting of
multiple lines by using \n if the buffer has input_multiline set.
The bug was fixed in version 2.0 (issue #1040) but a regression in version 3.7
happened while using the new IRC parser for message arguments (issue #1796,
commit 96ed471261).
This fixes an issue with IRC URL given on command line when it starts with
`ircs://` or `irc6://`: the server is not created at all (only `irc://` works
fine).
It seemed strange to me to have word_end_offset point to the last
character in the word, rather than the character after the word,
especially now with the word stopping before a newline character which
meant word_end_offset would be -1 if there was no characters before the
newline character.
The new rendering of multiline lines had some issues with colors at
certain positions not being applied. The color would not be applied if
the color code was at either of these positions:
- At the start of a line after a newline character
- At the end of a line after a space and before a newline character
- At a line by itself before a newline character
The way I had done it by considering newline characters as a word in
gui_chat_get_word_info with a variable specifying that it's newline
characters became messy and didn't really make sense, so rather than
doing this, I changed gui_chat_get_word_info to stop before the first
newline character. That way, we can just check if we are at a newline
character at the start of the loop, and don't need any more special
handling.
Fixes#1928
The status PRIVMSG and NOTICE are now displayed the same way for outgoing and
received messages:
Msg(alice) -> @#test: message for ops
Notice(alice) -> @#test: notice for ops
And any message like this is displayed with these tags if the nick is self
nick (case of a bouncer or if capability "echo-message" is enabled):
"self_msg", "notify_none", "no_highlight".
Regression was indirectly caused by commit
d18f68e497 in core that allows to display all
control chars in buffers.
But the fix is in script plugin: when the script is downloaded and read line by
line, trailing "\r" and "\n" are removed, and therefore not displayed.
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
With this function, buffer properties are set when the buffer is created and
can be read immediately by other plugins/scripts, for example in a callback of
signal "buffer_opened".
The function now allows only a single message. Newline chars ("\n") are allowed
in messages but not used as message separator.
This is a preparation work for the support of capability "draft/multiline".
For example typing this on core buffer:
/t1
/t2
was not executing the two commands but sent the text to the buffer instead.
This is because WeeChat thinks it's a path, and the newline should indicate
it's not (like a space before the next slash: "/t1 /t2" is a command, not a
path, but "/t1/t2" is considered a path).
The API functions `command` and `command_options` (when `split_newline` = 0,
which is the default value) don't split on newline and then the first line is
executed and the subsequent lines (after "\n") are ignored.
There are no changes when the input has multiple lines filled by the user: the
split is done and multiple commands are executed (for example if the user is
pasting multiple commands to execute).
Default value of option weechat.color.status_name_tls is set to white instead
of lightgreen.
Now all servers/channels connected with TLS are white, and those without TLS
are lightmagenta.
If you have a chat line with multiple lines that were scrolled so that
part of it is rendered at the bottom of the chat area, and part of it
falls below the chat area, there was a bug where the prefix_suffix would
be displayed at the end of the last line.
Looks like this happens because the gui_chat_display_prefix_suffix is
called for the line below the last line displayed in the chat area. So
we have to add a check for this so we don't add the prefix_suffix. This
check is copied from gui_chat_display_word which checks for the same.
Fixes#1912
This contains the single line that you focused on, like _chat_word
contains the word that you focused on. This will be equal to
_chat_line_message if the chat line only contains a single line, but if
the chat line has multiple lines, _chat_line_message will contain all of
them, but _chat_focused_line will only contain the single line that was
focused.
Fixes part of #1913
If we have chat lines with multiple lines in buffers without
input_multiline set, there can be an issue if a trigger is run on that
line. If the trigger runs a command which includes the message, then the
command is split (since input_multiline isn't set), and if any of the
lines in the message starts with a command, that command is executed.
To prevent this, only avoid splitting on newlines in printf if
input_multiline is set, so only such buffers can have chat lines with
newline characters.
See https://github.com/weechat/weechat/pull/1909 for more details.
With support for rendering newline characters as new lines, we don't
need to split the message on newline characters anymore in
printf_date_tags. This allows you to print a line with multiple lines.
If a chat line message contains a newline character (\n) it was
previously rendered as J with reverse video. This commit makes it
render as an actual newline instead, so messages with multiple lines
become supported.
The rendering is fixed in normal mode as well as bare mode both when
scrolled to the bottom and when scrolled up (which is different code
paths). Focus events has also been updated to support this (except for
_chat_line_y which returns -1 for all lines, but the docs says this
variable is only for buffers with free content).
Currently, the only way to include a \n in a chat line message is with
hdata_update because printf splits on \n and creates multiple separate
lines, but hopefully either printf can be changed to not split on \n, or
a new command which doesn't split can be added.
It seems no terminal return such codes any more for pgup/pgdn, and `meta-[I` is
conflicting with the xterm terminal "focus in" key code.
The keys are also removed from config when converting old keys, but only if
they are bound to the default command (`/window page_up` for `meta2-I` and
`/window page_down` for `meta2-G`).
Changes:
- build of doc now requires weechat-headless, translations and all plugins
- convert docgen.py to C
- remove `autogen_*` files from repository
- add command line parameter `--doc-gen` in `weechat-headless` to build
autogen files
- build .mo files with directories like the installed ones
(eg: "<lang>/LC_MESSAGES/weechat.mo")
- remove javascript chapter from user's guide
This does the same as the lead_linebreak option in multiline.pl. That
is, when the input contains more than one line, the first line will be
displayed beneath the previous items in the bar. This is practical
because all the lines in the input will be aligned.
Related to #1498
This changes the commands delete_beginning_of_line, delete_end_of_line,
delete_line, move_beginning_of_line and move_end_of_line to operate on
the current line instead of the whole input. The commands
delete_beginning_of_input, delete_end_of_input, delete_input,
move_beginning_of_input and move_end_of_input are added with the
previous implementations that the line commands had.
Additionally, the commands move_previous_line and move_next_line are
added which moves the cursor to the previous/next line and keeps the
horizontal position in the line.
The meta-r key is changed from delete_line to delete_input to keep the
behavior, and because you probably want to delete the whole input more
often than the line. The meta-R key is added for delete_line.
The home, end, ctrl-u and ctrl-k keys are kept to the same commands,
which means that they change behaviour. This is because having them
operate on the line is consistent with other applications (vim, zsh),
and I also think it's more practical.
These new bindings are added:
shift-home: /input move_beginning_of_input
shift-end: /input move_end_of_input
shift-up: /input move_previous_line
shift-down: /input move_next_line
meta-R: /input delete_line
meta-ctrl-u: /input delete_beginning_of_input
meta-ctrl-k: /input delete_end_of_input
Relates to #1498
The previous commit e385eec1d6 fixed default
value for bar added by plugins and option "items" in all bars.
This commit fixes the default value of all bar options.
Now that pasting text doesn't cause it to be sent immediately, but
rather inserted in the input line, the paste confirmation isn't really
necessary anymore for small pastes. If you paste by mistake you can just
press ctrl-_ to undo it.
Large pastes may cause weechat to hang for a while, so keep the paste
confirmation for those.
If you don't use bracketed paste you would still want to keep it at 1,
because it's not detected as a paste otherwise, but as far as I know
basically all terminal emulators support bracketed paste, so I think
it's fine to disable the confirmation by default.
This option existed so that you could edit the last line of a multiline
paste before it was sent. Now that pasting multiple lines don't cause
the lines to be sent immediately anymore, this option isn't useful
anymore since you can always edit pasted text before it's sent.
Since pasting doesn't send the line now, it's more practical to always
remove the final newline so you don't end up with an empty line at the
end of the input buffer.
Fixes a part of #1498
Instead of replacing newline/tabs when paste is started, do it when the
paste is accepted instead. This makes a difference if you paste again
while the paste confirmation is active, where instead of running it
again for each paste, it will now be run for all the text at the end.
For now this doesn't make a practical difference, but the next commit
will remove the final newline when multiple lines are pasted too, which
we only want to do for the final paste.
This makes pasted text appear in the input bar, instead of each line
being sent. This allows you to edit the text before sending it, and it
makes multiline paste supported in buffers with input_multiline on.
It also replaces \r with \n in pasted text because most terminals (e.g.
xterm and urxvt) print lines separated by \r when pasting as if return
was pressed between each line, even though the copied text uses \n. The
text sent to the buffer should use \n, not \r, so we have to replace it.
Note that this only works when bracketed paste is enabled or the paste
confirmation as shown, because non-bracketed paste with no paste
confirmation is not detected as a paste.
Fixes a part of #1498
When in paste pending mode, the bracketed paste escape sequence should
still be interpreted, so that if you paste while in paste pending the
same things as when pasting in normal mode still happens, i.e. the
escape sequence is removed, ctrl-y/n is not interpreted and newline/tabs
are replaced.
When the bar name already exists, the function `bar_new` returns the pointer to
the bar (instead of NULL) and sets the default value for all options with the
values received.
When raw code and alias for a key are both matching, the raw code must always
have higher priority.
This commit fixes this behavior and gives priority to raw code.
Changes:
- add function gui_key_debug_print_key
- change message "no key" by "no key binding"
- remove messages ""insert into input" / "ignored"
- add color for delimiters
Now when fset plugin is loaded, the keys are displayed in fset buffer.
In core commands like /set or /key, the fset plugin is not mentioned as WeeChat
can run without it.
Keys added in mouse context were already hidden, so it makes sense to not
display keys in default context as well.
These keys added by the default plugins are documented anyway.
When the input buffer contains non word characters at the end, /input
move_next_word will stop moving at the end of the last word. This is
a bit confusing and not in line with what readline does (think bash).
When there are no words left in the input buffer, make /input
move_next_word go to the end of line.
Signed-off-by: Robin Jarry <robin@jarry.cc>
Two new fields are added in IRC server structure:
- "authentication_method", possible values:
0: not authenticated
1: authenticated with SASL
2: authenticated with other method
- "sasl_mechanism_used", possible values: see enum t_irc_sasl_mechanism
in src/plugins/irc/irc-sasl.h
Priority is now allowed in function config_file_new, parameter `name`, with the
same format as hooks: "priority|name" (for example: "2000|test").
If not specified, the default priority is 1000.
Now the autojoin is made only one time, until the server buffer is closed.
A new flag `autojoin_done` is added to know whether the autojoin has already
been done or not on the server. It is set to 1 on first autojoin, and reset to
0 only if the server buffer is closed.
The flag `reconnect_join` is removed, because it is now obsolete.
This script is now used in CI to check all shell scripts (*.sh) and Python
scripts (*.py) that are in git repository.
Tools used:
- shell scripts: shellcheck
- Python scripts: flake8 + pylint + bandit
This fixes the following shellcheck error:
SC2294 (warning): eval negates the benefit of arrays. Drop eval to preserve
whitespace/symbols (or eval as string).
All lowercase letters are now properly converted to uppercase letters (and vice
versa), via functions `towupper` and `towlower`.
Functions `string_tolower`, `string_toupper` and `utf8_charcasecmp` have been
optimized to be faster when there are ASCII chars (< 128); functions are about
25-40% faster with mixed chars (both ASCII and multi-bytes).
Function `utf8_wide_char` has been removed, `utf8_char_int` can be used
instead.
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
When there non printable chars, the return of the function was 1.
For example utf8_strlen_screen("abc\x01") now returns 4 instead of 1.
In addition the function has been optimized to not use the `mbstowcs` function
which is slow; result is up to 15% faster.
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).
If a color option value is null and is tried being set to an invalid
color, the value was set to uninitialized memory which can lead to a
segfault.
Can be reproduced with this script:
https://gist.github.com/trygveaa/6ddb3a52f525a7fd8e0908bafa83e07c
The option doesn't have to be set from a script, it also happens with
the /set command.
This affects the following hook types:
- command
- command_run
- line
- modifier
- print
This fixes a regression introduced in WeeChat 3.7 by commit
0f67f55098.
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.
util_version_number returns an int, but BYTES_EQUAL only compares the
last byte of the int, so it wouldn't test the rest of the int.
I see other tests for functions returning an int use LONGS_EQUAL, so
that seems correct to use.
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.
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.
This fixes such error displayed on Termux when receiving a DCC file:
xfer: invalid address "96747949": error 8 hostname nor servname provided, or not known
This was preventing the PHP plugin from working if PHP was compiled
with `--enable-debug`. With this patch, `--enable-debug` builds of
PHP should work.
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.
When changing the options weechat.network.gnutls_ca_system or
weechat.network.gnutls_ca_user, the GnuTLS credentials are freed then allocated
again, but the verification function used to check the certificate on
connection is not set again.
As a consequence, any TLS connection is made without checking the certificate.
This regression was introduced in version 3.2, when the options were changed to
automatically load system certificates without having to give the path, and to
let user give an extra custom path with certificates.
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
This fixes the compilation warning:
weechat-guile.c: In function ‘weechat_plugin_init’:
weechat-guile.c:1270:5: warning: ‘scm_install_gmp_memory_functions’ is deprecated [-Wdeprecated-declarations]
There is no problem in practice because the possible URL prefixes are hardcoded
in the spell plugin and don't contain any UTF-8 char on more than one byte.
There is no problem in practice because this server nonce is generated by
WeeChat itself and encoded to base64, so it never contains any UTF-8 char on
more than one byte.
Option relay.network.compression_level is renamed to relay.network.compression
and is now a percentage between 0 (no compression) to 100 (best compression,
slowest).
Compression is now disabled by default in weechat protocol and must be enabled
via the `handshake` command (option `compression` has been removed from `init`
command).
New options in command /input:
- hotlist_remove_buffer
- hotlist_restore_buffer
- hotlist_restore_all
New keys:
- alt+h, alt+c: clear the whole hotlist (former key: alt+h)
- alt+h, alt+m: mark the current buffer as read by removing it from the hotlist
- alt+h, alt+r: restore latest hotlist removed in the current buffer
- alt+h, alt+shift+R: restore latest hotlist removed in all buffers
Add some references between the Screen layout and Buffers and windows
sections, linking also to the appropriate commands.
This should make it easier to discover the `/layout` command and its
relevance to the windows and buffer management.
(Small contribution to GitHub issue #1641)
(max) bar size was described to be in chars, though this only applies to the left/right bars. This change clarifies that top/bottom bars would have their size defined in lines.
wee-eval.c calls gettext directly, but gettext is not a function if
ENABLE_NLS is off. Fix by defining a gettext macro (that expands to its
first argument) if NLS support is disabled.
This constant was introduced in GnuTLS 3.6.3.
This fixes a build error on these old distributions:
- Debian Stretch
- Debian Jessie
- Ubuntu Bionic
- Ubuntu Xenial
The text "cleartext" is translated for display only: directly with gettext in
IRC plugin and with "${translate:${tls_version}}" in the buflist evaluated
format.
In cf93e953b the `weechat.bar.*.condition` examples have been changed to use
`${info:term_width}` instead of `${window.win_width}`. The user guide still
shows the old example. This commit syncs the user guide with the on-line help.
This reverts commit 1df1903d23.
This is not so easy to implement: it requires saving state of plugins, and
plugins like irc can not save the connected state (except in a real upgrade
case where the sockets are still valid after exec of the new binary).
To force evaluation of the expression before doing the comparison (less safe),
the "${eval_cond:xxx}" can be used.
With the old behavior we had:
>> ${if:a==b}
== [0]
>> ${if:${raw:a==b}}
== [0]
>> ${if:${eval_cond:${raw:a==b}}}
== [0]
And with the new behavior, we have:
>> ${if:a==b}
== [0]
>> ${if:${raw:a==b}}
== [1]
>> ${if:${eval_cond:${raw:a==b}}}
== [0]
This used pointer1 and pointer2 which are pointers to the buffers, but
it should use ptr_hotlist1 and ptr_hotlist1 which are pointers to the
hotlists it is trying to compare.
If you run /input jump_next_visited_buffer right after switching to a
buffer, weechat changes to the first buffer in the visited buffers list.
That is, it wraps around and goes to the buffer you visited the longest
ago. This patch fixes that.
The reason it happens is that when you switch to a buffer (normally,
i.e. in another way than using jump_previously_visited_buffer/
jump_next_visited_buffer) gui_buffers_visited_index is set to -1 (in
gui_buffer_visited_add). This makes gui_buffer_visited_get_index_next
return 0 because it returns gui_buffers_visited_index + 1, which makes
gui_input_jump_next_visited_buffer jump to the first buffer in the list
of visited buffers.
Fixes#1591
These two formats are now supported, if "pointer_name" is present in the
"pointers" hashtable:
* "${pointer_name}": value of pointer (example: "0x1234abcd")
* ${buffer[pointer_name].full_name}: use of a pointer name instead of pointer
value or list name
New options to customize behavior on signals received, with the default
behavior:
- weechat.signal.sighup: quit in normal mode, reload config in headless
- weechat.signal.sigquit: quit
- weechat.signal.sigterm: quit
- weechat.signal.sigusr1: no command executed by default
- weechat.signal.sigusr2: no command executed by default
The signals SIGUSR1 and SIGUSR2 are introduced by this commit, so it's now
possible to run commands when they are received.
The SIGHUP signal makes now WeeChat quit, it was the behavior before version
2.9 of WeeChat (see commit de1e61f7cd).
Use "!" instead of "@" to separate nick from host, like it is done in IRC
protocol.
The nick and host is now displayed as "nick!user@host" instead of
"nick@user@host".
Both default to "on" (no change to previous behavior).
If hotlist_update_on_buffer_switch is "off", then when switching away from a
buffer, the hotlist is not cleared.
If read_marker_update_on_buffer_switch is "off", then when switching away from
a buffer, the read marker is not set to the end of the buffer.
This allows users to choose to have fully manual control over when hotlist
counts and buffer read markers are reset.
Fixes#992.
The command is used to read the passphrase on startup, for example using your
favorite password manager.
Note: only the passphrase is read from the program, the secured data is still
stored encrypted in sec.conf and handled by WeeChat itself.
This fixes the following warning:
/usr/bin/xgettext: warning: msgid 'server' is used without plural and with plural.
./src/plugins/irc/irc-bar-item.c:136: Here is the occurrence without plural.
./src/plugins/irc/irc.c:154: Here is the occurrence with plural.
Workaround: If the msgid is a sentence, change the wording of the sentence; otherwise, use contexts for disambiguation.
Now a single -d in command /eval shows less debug messages than previous
versions.
To get the same debug messages than previous versions, two -d must be used.
The option "localvar" (introduced long time ago, in WeeChat 0.3.0) is still
recognized by WeeChat, to stay compatible with any extension/script calling
it (or referencing it in the documentation).
It is deprecated and will be removed in a future release.
When this local variable is set, it overrides the value of option
"weechat.completion.default_template".
It is evaluated, that means the global default template can be used to append
some custom completion. For example:
/buffer set localvar_set_completion_default_template ${weechat.completion.default_template}|%(my_completion)
This reverts commit 4ff4a64209.
These compiler flags are not supported on old compiler version, for example on
Debian Stretch/Jessie and Ubuntu Xenial (16.04).
When the input is empty, length of string is zero: when sending zero to
function weechat_string_dyn_alloc, the function returns NULL and therefore we
return immediately instead of handling the empty input, which is a valid value.
The regression was introduced by the use of dynamic strings, commit:
299f74bfef
Before submitting a bug, please check that it has not already been reported by searching in [open and closed bugs](https://github.com/weechat/weechat/issues?q=is%3Aissue+label%3Abug).
If you don't use the latest version, please try if possible with the latest stable release to be sure the issue is still present and report the issue on this version.
**IMPORTANT**: please do not report any security issue here, see [CONTRIBUTING.md](https://github.com/weechat/weechat/blob/main/CONTRIBUTING.md#security-reports).
- type:textarea
id:bug-description
attributes:
label:Describe the bug
description:A clear and concise description of what the bug is.
validations:
required:true
- type:textarea
id:steps-to-reproduce
attributes:
label:Steps to reproduce
description:|
Steps to reproduce the issue.
If possible, please try to reproduce with a default configuration and no scripts loaded (`weechat -t`). If the issue is related to a script, please mention the list of all scripts loaded.
placeholder:|
1.
2.
3.
validations:
required:true
- type:textarea
id:current-behavior
attributes:
label:Current behavior
description:|
What currently happens.
validations:
required:true
- type:textarea
id:expected-behavior
attributes:
label:Expected behavior
description:What is actually supposed to happen.
validations:
required:true
- type:textarea
id:suggested-solutions
attributes:
label:Suggested solutions
description:How you think this issue can be resolved.
validations:
required:false
- type:textarea
id:additional-information
attributes:
label:Additional information
description:|
For a crash, please include a backtrace from gdb, see the [User's guide](https://weechat.org/doc/weechat/user/#report_crashes).
For a display issue, please add a screenshot if it makes sense.
Please mention if other versions are affected as well and if some versions are not affected (regression?).
And any additional information you deem relevant.
validations:
required:false
- type:input
id:weechat-version
attributes:
label:WeeChat version
description:|
For a stable release: output of `weechat --version`.
For the development version: output of command `/v` in WeeChat.
placeholder:"4.1.1"
validations:
required:true
- type:input
id:os-version
attributes:
label:What OS/distribution are you using?
description:Name of the operating system and its version.
Before submitting a feature request, please check that it has not already been reported by searching in [open and closed feature requests](https://github.com/weechat/weechat/issues?q=is%3Aissue+label%3Afeature).
- type:textarea
id:feature
attributes:
label:Feature description
description:A description of the feature you would like.
- please read the [FAQ](https://weechat.org/doc/weechat/faq) and [documentation](https://weechat.org/doc/weechat/)
- please ask on #weechat channel (on server irc.libera.chat).
**IMPORTANT**: please do not report any security issue here, see [CONTRIBUTING.md](https://github.com/weechat/weechat/blob/main/CONTRIBUTING.md#security-reports).
STRING"WeeChat home directory for config, logs, scripts.. (default is \"~/.weechat\")"
STRING"Force a single WeeChat home directory for config, logs, scripts, etc."
FORCE)
mark_as_advanced(CLEARWEECHAT_HOME)
# option CA_FILE
if(NOTDEFINEDCA_FILEOR"${CA_FILE}"STREQUAL"")
set(CA_FILE"/etc/ssl/certs/ca-certificates.crt")
endif()
set(CA_FILE"${CA_FILE}"CACHE
STRING"File containing the certificate authorities (default is \"/etc/ssl/certs/ca-certificates.crt\"). This is the default value of option \"weechat.network.gnutls_ca_file\"."
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for software and other kinds of works.
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.
Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS
0. Definitions.
“This License” refers to version 3 of the GNU General Public License.
“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
A “covered work” means either the unmodified Program or a work based on the Program.
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
7. Additional Terms.
“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
11. Patents.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”.
A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <https://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <https://www.gnu.org/philosophy/why-not-lgpl.html>.
*WeeChat* (Wee Enhanced Environment for Chat) is a free chat client, fast and
light, designed for many operating systems.
It is highly customizable and extensible with scripts.
Homepage: https://weechat.org/
== Features
* *Modular chat client*: WeeChat has a lightweight core and optional https://weechat.org/files/doc/stable/weechat_user.en.html#plugins[plugins]. All plugins (including https://weechat.org/files/doc/stable/weechat_user.en.html#irc_plugin[IRC]) are independent and can be unloaded.
* *Multi-platform*: WeeChat runs on GNU/Linux, *BSD, GNU/Hurd, Haiku, macOS and Windows (Bash/Ubuntu and Cygwin).
* *Multi-protocols*: WeeChat is designed to support multiple protocols by plugins, like IRC.
* *Standards-compliant*: the IRC plugin is compliant with RFCs https://tools.ietf.org/html/rfc1459[1459], https://tools.ietf.org/html/rfc2810[2810], https://tools.ietf.org/html/rfc2811[2811], https://tools.ietf.org/html/rfc2812[2812] and https://tools.ietf.org/html/rfc2813[2813].
* *Small, fast and very light*: the core is and should stay as light and fast as possible.
* *Customizable and extensible*: there are a lot of options to customize WeeChat, and it is extensible with C plugins and https://weechat.org/scripts/[scripts] (https://weechat.org/scripts/stable/language/perl/[Perl], https://weechat.org/scripts/stable/language/python/[Python], https://weechat.org/scripts/stable/language/ruby[Ruby], https://weechat.org/scripts/stable/language/lua/[Lua], https://weechat.org/scripts/stable/language/tcl/[Tcl], https://weechat.org/scripts/stable/language/guile/[Scheme], https://weechat.org/scripts/stable/language/javascript/[JavaScript] and https://weechat.org/scripts/stable/language/php/[PHP]).
* *Fully documented*: there is comprehensive https://weechat.org/doc/[documentation], which is https://weechat.org/files/doc/stable/weechat_dev.en.html#translations[translated] into several languages.
* *Developed from scratch*: WeeChat was built from scratch and is not based on any other client.
* *Free software*: WeeChat is released under https://www.gnu.org/licenses/gpl-3.0.html[GPLv3].
- **Modular chat client**: WeeChat has a lightweight core and optional [plugins](https://weechat.org/doc/weechat/user/#plugins). All plugins (including [IRC](https://weechat.org/doc/weechat/user/#irc)) are independent and can be unloaded.
- **Multi-platform**: WeeChat runs on GNU/Linux, *BSD, GNU/Hurd, Haiku, macOS and Windows (WSL and Cygwin).
- **Multi-protocol**: WeeChat is designed to support multiple protocols via plugins, like IRC.
- **Standards-compliant**: the IRC plugin is compliant with RFCs [1459](https://datatracker.ietf.org/doc/html/rfc1459), [2810](https://datatracker.ietf.org/doc/html/rfc2810), [2811](https://datatracker.ietf.org/doc/html/rfc2811), [2812](https://datatracker.ietf.org/doc/html/rfc2812), [2813](https://datatracker.ietf.org/doc/html/rfc2813) and [7194](https://datatracker.ietf.org/doc/html/rfc7194).
- **Small, fast, and very light**: the core is and should stay as light and fast as possible.
- **Customizable and extensible**: there are a lot of options to customize WeeChat, and it is extensible with C plugins and [scripts](https://weechat.org/scripts/) ([Perl](https://weechat.org/scripts/language/perl/), [Python](https://weechat.org/scripts/language/python/), [Ruby](https://weechat.org/scripts/language/ruby/), [Lua](https://weechat.org/scripts/language/lua/), [Tcl](https://weechat.org/scripts/language/tcl/), [Scheme](https://weechat.org/scripts/language/guile/), [JavaScript](https://weechat.org/scripts/language/javascript/) and [PHP](https://weechat.org/scripts/language/php/)).
- **Fully documented**: there is comprehensive [documentation](https://weechat.org/doc/weechat/), which is [translated](https://weechat.org/doc/weechat/dev/#translations) into several languages.
- **Developed from scratch**: WeeChat was built from scratch and is not based on any other client.
- **Free software**: WeeChat is released under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.html).
| Older releases | :x: | Not supported. Contact us in case of specific need. |
However, we may help to backport fixes on older versions, especially when they are used in released distributions with no way to upgrade to the latest stable release (please contact us).
## Reporting a vulnerability
Please report security issues using <https://github.com/weechat/weechat/security/advisories/new>.
Alternatively, if you are not able to use this form, you can send an email to [security@weechat.org](mailto:security@weechat.org) instead.
We will investigate all legitimate reports and do our best to quickly fix the problem.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Sébastien Helleu