Describe the bug
In Windows I've never had the Mark Range feature work, upon some investigation I see that it is likely related to ConPTY and how it handles a variety of special character sequences including ctrl-space, ctrl-m, etc.
I've verified ctrl-space isn't being caught by the OS or any other application including Windows Terminal.
There are likely ways to make ctrl+space work in Windows Terminal but it's likely pretty involved and handling special characters in an entirely different manner.
To Reproduce
Steps to reproduce the behavior:
- Open k9s in Windows Terminal (in Windows 10/11, unsure about past versions)
- Try to use Mark Range feature
- See it only act like you just selected one item not the whole rnage
Historical Documents
There are a few issues in the k9s repo of others experiencing this, but at least one person saying it worked in WSL on Windows but maybe not Windows Terminal, it's unclear.
Issue #2187
Issue #1653
Here is an issue related to this for the tcell library.
gdamore/tcell#653
Here are some related Windows Terminal Issues.
microsoft/terminal#2865
microsoft/terminal#15939
microsoft/terminal#16298
Expected behavior
Mark Range should work as expected in Windows Terminal.
Versions (please complete the following information):
- OS: [Windows 10/11]
- K9s: [0.50.6, 0.50.9, others but I didn't test back versions]
- K8s: [probably all versions, this is unrelated to k8s APIs]
Additional context
I'm opening a PR with a "fix" after a brief discussion in Slack about the options. The PR introduces an ENV variable K9S_USE_MARK_RANGE_ALT_KEY and an automatic check of whether k9s is open in Windows Terminal. If either of those checks comes back positive it will change Mark Range key bindings so that ctrl-j is used for Mark range. I don't know of a good way to detect whether or not we're behind Windows ConPTY which is likely where this is being broken.
Describe the bug
In Windows I've never had the Mark Range feature work, upon some investigation I see that it is likely related to ConPTY and how it handles a variety of special character sequences including ctrl-space, ctrl-m, etc.
I've verified ctrl-space isn't being caught by the OS or any other application including Windows Terminal.
There are likely ways to make ctrl+space work in Windows Terminal but it's likely pretty involved and handling special characters in an entirely different manner.
To Reproduce
Steps to reproduce the behavior:
Historical Documents
There are a few issues in the k9s repo of others experiencing this, but at least one person saying it worked in WSL on Windows but maybe not Windows Terminal, it's unclear.
Issue #2187
Issue #1653
Here is an issue related to this for the tcell library.
gdamore/tcell#653
Here are some related Windows Terminal Issues.
microsoft/terminal#2865
microsoft/terminal#15939
microsoft/terminal#16298
Expected behavior
Mark Range should work as expected in Windows Terminal.
Versions (please complete the following information):
Additional context
I'm opening a PR with a "fix" after a brief discussion in Slack about the options. The PR introduces an ENV variable K9S_USE_MARK_RANGE_ALT_KEY and an automatic check of whether k9s is open in Windows Terminal. If either of those checks comes back positive it will change Mark Range key bindings so that ctrl-j is used for Mark range. I don't know of a good way to detect whether or not we're behind Windows ConPTY which is likely where this is being broken.