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
disable bracketed paste during the execution of a child #10998
disable bracketed paste during the execution of a child #10998
Conversation
if engine_state.get_config().bracketed_paste { | ||
#[cfg(not(target_os = "windows"))] |
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.
This should probably stay because I don't believe bracketed paste is supported on Windows yet. IIRC, there was a crossterm issue about it, unless you're saying that's been fixed?
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.
This should probably stay because I don't believe bracketed paste is supported on Windows yet. IIRC, there was a crossterm issue about it, unless you're saying that's been fixed?
I haven't looked into bracketed_paste much from the crossterm side. However it should be totally dependent on the terminal, not on the OS itself. And we can't assume that a windows user is using any specific terminal.
This is why I asked for multiple people to test it on multiple platforms, to see if something breaks.
I don't like the solution of giving Windows users a configuration setting that is silently ignored either. Either they can or they can't configure bracketed paste.
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.
If bracketed paste isn't supported in a certain terminal (some unix terminals might not support it either) at its worst the control characters are probably just ignored. So there should be no harm in having it enabled on a terminal that does not support it.
According to crossterm-rs/crossterm#737, bracketed paste does work in WizTerm on Windows.
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.
I'm not super sure how to test this to ensure my buffer has the appropriate escape sequences when I paste them. But these seem to work on Windows Terminal and WezTerm.
❯ $"(ansi csi)200~this is a test(ansi csi)201~"
this is a test
❯ $"(ansi csi)?2004h(ansi csi)200~this is a test(ansi csi)201~(ansi csi)?2004l"
this is a test
It would also be good to have |
This shouldn't have negative effects on the reedline crate before the patch. If you want to bump the reedline version in nushell you'll have to release a new reedline version. |
I'm saying that we should be testing with the latest version of reedline so |
But reedline is still on version Are you saying I should commit the updated Cargo. |
Actually you don't need to, I found that it already use latest git commit of reedline |
I think it uses whatever version is specified in the lockfile. I compiled nushell from a fresh clone, and it still had nushell/reedline#648, the bug where bracketed_paste only works the first time because it gets disabled after the first time. Then I ran
I was wrong thinking that the |
I updated the commit hash, but I really think it would be better if reedline would just release regular patch version bumps. |
This is why I asked you to do it the other day. Glad you figured it out. I think at this point I'd like to see what @sholderbach's PR reveals nushell/reedline#659 and how it intersects with this PR. |
Go from the ill-defined `enable/disable` pairs to `.use_...` builders This alleviates unclear properties when the underlying enhancements are enabled. Now they are enabed when entering `Reedline::read_line` and disabled when exiting that. Furthermore allow setting `$env.config.use_kitty_protocol` to have an effect when toggling during runtime. Previously it was only enabled when receiving a value from `config.nu`. I kept the warning code there to not pollute the log. We could move it into the REPL-loop if desired Not sure if we should actively block the enabling of `bracketed_paste` on Windows. Need to test what happens if it just doesn't do anything we could remove the `cfg!` switch. At least for WSL2 Windows Terminal already supports bracketed paste. `target_os = windows` is a bad predictor for `conhost.exe`. Depends on nushell/reedline#659 (pointing to personal fork) Closes nushell#10982 Supersedes nushell#10998
Go from the ill-defined `enable/disable` pairs to `.use_...` builders This alleviates unclear properties when the underlying enhancements are enabled. Now they are enabed when entering `Reedline::read_line` and disabled when exiting that. Furthermore allow setting `$env.config.use_kitty_protocol` to have an effect when toggling during runtime. Previously it was only enabled when receiving a value from `config.nu`. I kept the warning code there to not pollute the log. We could move it into the REPL-loop if desired Not sure if we should actively block the enabling of `bracketed_paste` on Windows. Need to test what happens if it just doesn't do anything we could remove the `cfg!` switch. At least for WSL2 Windows Terminal already supports bracketed paste. `target_os = windows` is a bad predictor for `conhost.exe`. Depends on nushell/reedline#659 (pointing to personal fork) Closes #10982 Supersedes #10998
Thanks for the PR @LevitatingBusinessMan superseded by #11045 |
Go from the ill-defined `enable/disable` pairs to `.use_...` builders This alleviates unclear properties when the underlying enhancements are enabled. Now they are enabed when entering `Reedline::read_line` and disabled when exiting that. Furthermore allow setting `$env.config.use_kitty_protocol` to have an effect when toggling during runtime. Previously it was only enabled when receiving a value from `config.nu`. I kept the warning code there to not pollute the log. We could move it into the REPL-loop if desired Not sure if we should actively block the enabling of `bracketed_paste` on Windows. Need to test what happens if it just doesn't do anything we could remove the `cfg!` switch. At least for WSL2 Windows Terminal already supports bracketed paste. `target_os = windows` is a bad predictor for `conhost.exe`. Depends on nushell/reedline#659 (pointing to personal fork) Closes nushell#10982 Supersedes nushell#10998
Go from the ill-defined `enable/disable` pairs to `.use_...` builders This alleviates unclear properties when the underlying enhancements are enabled. Now they are enabed when entering `Reedline::read_line` and disabled when exiting that. Furthermore allow setting `$env.config.use_kitty_protocol` to have an effect when toggling during runtime. Previously it was only enabled when receiving a value from `config.nu`. I kept the warning code there to not pollute the log. We could move it into the REPL-loop if desired Not sure if we should actively block the enabling of `bracketed_paste` on Windows. Need to test what happens if it just doesn't do anything we could remove the `cfg!` switch. At least for WSL2 Windows Terminal already supports bracketed paste. `target_os = windows` is a bad predictor for `conhost.exe`. Depends on nushell/reedline#659 (pointing to personal fork) Closes nushell#10982 Supersedes nushell#10998
Fixes #10982
Based on by #9399 by @WindSoilder.
I invite @WindSoilder, @fdncred and @theAkito to test this on their respective platforms.
I can't say I completely understand nushells cli code, but based on @WindSoilder I assumed
eval_source
was responsible for executing the child program.This PR disables bracketed paste during the execution of children for reasons I explained in #10982.
To test:
With this all bracketed paste issues should be fixed.