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.
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).
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).
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`).
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.
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
Sébastien Helleu