-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove conflicting keybindings added with selection feature #715
Conversation
Thanks! |
kb.add_binding( | ||
KM::CONTROL | KM::SHIFT, | ||
KC::Char('c'), | ||
edit_bind(EC::CopySelection), | ||
); | ||
kb.add_binding( | ||
KM::CONTROL | KM::SHIFT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While not in conflict with any of the reedline default emacs-inspired bindings, most GUI terminal emulators that provide their own independent means of selection will intercept Ctrl-Shift-C
and Ctrl-Shift-V
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is your suggestion @sholderbach?
Here's my brief survey of the terminals I have installed on my mac. Some of them do selection, some won't. Some see ctrl-shift-anything as ctrl-anything according to keybindings listen. I think some could be made to work by disabling built-in ctrl-shift-anything.
Ghostty - works
Alacritty - works
iterm2 - does not work
wezterm - does not work
terminal.app - does not work
tabby - does not work
warp - does not work, selection doesn't even work
cool-retro-term - does not work, selection doesn't even work
kitty - does not work
rio - does not work
zed built-in terminal - does not work
vscode built-in terminal - does not work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of free keybinds which are part of the lowest common denominator accross the different terminals is certainly limited. Pretty likely that we would have to settle for something pretty unidiomatic/non-mnemonic if we want to squeeze it among everything people expect from bash readline/emacs. Maybe we would at some point add an additional editmode (that is not modal) to cover more GUI-like keybindings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to support a "pure" shell mode? Without emacs or vim bindings? I personally want to use nushell first and foremost as a shell. For my use case it would prioritise stuff like selection, history and stuff like that much higher than replicating terminal editor functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds interesting. How would you do that?
Removes some conflicting keybindings introduced with #689
Fixes issue nushell/nushell#11600
The issue was that Ctrl+C was bound to copy the selected test after the already existing CtrlC command.