Repository navigation
Strange behaviour of CTRL+K #112
Description
With CTRL + K it is possible to delete a whole line. At least this works. The cursor then sits on an empty line. Usually pressing CTRL + K again would pull up the next line and delete this as well. The idea is to press CTRL + K multiple times and deltetes all the lines one by one. However wmux is just deleting one line and then doing nothing when repeated on that empty line. I am using windows so i can say whether this works in linux or on the mac. Would be nice if this could be fixed because it is a bit annoying :)
Activity
amirlehmam commentedon Jul 22, 2026
Thanks for the report — I dug into this and want to share what I found, because the result is a bit counter-intuitive.
What wmux does with Ctrl+K: I audited the full input path (renderer shortcut layer, xterm custom key handler, ConPTY write path). wmux does not intercept, throttle, or transform Ctrl+K anywhere — every single press is delivered to the running application as the byte
0x0B(the standard VT encoding of Ctrl+K), identical on the first press and every repeat. There is no state in wmux that could make press #2 behave differently from press #1. This is byte-for-byte the same thing Windows Terminal delivers.Why the behavior differs anyway: a terminal only transmits bytes — what Ctrl+K does is decided entirely by the program receiving it (your shell or coding tool's line editor). The behavior you're describing is emacs/readline
kill-linesemantics:The second half is a feature of the application's editor, not the terminal. Apps that implement "kill to end of line" but not "kill the newline when the line is empty" will show exactly what you observed — and they'll show it in Windows Terminal, kitty, etc. as well, since the input bytes are identical.
To pinpoint it, could you tell us:
modifyOtherKeys, which xterm.js — wmux's terminal engine — doesn't support yet), and that would be genuinely actionable on our side.If it turns out to be the app's editor, the fix belongs upstream in that tool, but I'm happy to help confirm and point you at the right place. Leaving this open pending your reply.
amirlehmam commentedon Jul 24, 2026
Closing this one out, since there's been no reply and the audit above didn't turn up anything actionable on the wmux side.
To summarize for anyone who finds this later: wmux delivers Ctrl+K to the running program as the byte
0x0Bon every press, first and subsequent, with no interception or state in between — byte-for-byte what Windows Terminal sends. What Ctrl+K does is decided by the program receiving it. The behaviour described (kills to end of line, then does nothing on the now-empty line) is an application whose line editor implementskill-linebut not the "kill the newline when the line is already empty" half of readline's semantics. That will look identical in any terminal.Happy to reopen if you can show the same program behaving differently in Windows Terminal on the same machine — that would point at something real on our end (most likely the kitty keyboard protocol /
modifyOtherKeys, which xterm.js doesn't negotiate yet), and it'd be worth a separate issue with that framing.arnonuem commentedon Aug 3, 2026
@amirlehmam is it maybe somehow possible that i can write a plugin for myself to add this behaviour to wmux?
For example when ever CTRL+K is pressed, let it follow with the DEL key once.
amirlehmam commentedon Aug 5, 2026
Follow-up for anyone who finds this: the audit above still stands — wmux sends
0x0Bon every Ctrl+K press and the "pull the next line up" half belongs to the receiving program's line editor. But as of 0.44.0 you can make wmux send something else, which covers the case from the terminal side (see #146):Ctrl+K then transmits kill-line followed by Delete, on every press.
wmux reload-configapplies it without a restart. Full token list in docs/config.md.