Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
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.
|
|
config_set_plugin and config_set_desc_plugin
|
|
(issue #1736)
|
|
|
|
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.
|
|
focus data (closes #1955)
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").
|
|
This info returns a pointer buffer with its full name.
|
|
Key Alt+K (upper K) is removed as well as commands `/input grab_raw_key` and
`/input grab_raw_key_command`.
|
|
|
|
|
|
|
|
|
|
|
|
weechat protocol
|
|
They are used in completion of commands `/filter disable` and
`/filter enable`.
|
|
They are used in completion of commands `/trigger disable` and
`/trigger enable`.
|
|
Regression was indirectly caused by commit
d18f68e497c4244404ff8f4f50de82717b178e09 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".
|
|
|
|
|
|
|
|
(issue #1926)
|
|
#1808)
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
capability) and not sending "CAP END" (issue #1040, issue #1796)
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 96ed47126130ac62350aef4a9236009b7fc3cd5f).
|
|
"relay_client_irc_out"
|
|
This option was broken with commit 031bd45e3.
|
|
issue #1886)
|
|
plugins, add info "auto_load_scripts"
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
|
|
|
|
irc_input_user_message_display
|
|
(issue #139)
|
|
|
|
|
|
(issue #1577)
|