summaryrefslogtreecommitdiff
path: root/src/gui/curses/gui-curses-key.c
diff options
context:
space:
mode:
authorTrygve Aaberge <trygveaa@gmail.com>2023-07-03 21:59:09 +0200
committerSébastien Helleu <flashcode@flashtux.org>2023-07-03 23:02:21 +0200
commit824cfb64277213aca89dfba5f0b474f94f6dd482 (patch)
treea564f2616807cdac0786ccaac58dc4f135e8c021 /src/gui/curses/gui-curses-key.c
parent7b5585239f64ed013f5acf476ae961b97a588708 (diff)
downloadweechat-824cfb64277213aca89dfba5f0b474f94f6dd482.zip
core: don't send key_combo_* signals for incomplete keys
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).
Diffstat (limited to 'src/gui/curses/gui-curses-key.c')
0 files changed, 0 insertions, 0 deletions