nushell replicates prompt line with every keystroke on wezterm
#5585
Comments
|
one idea is to try to compile and run reedline by itself, just to see if there's something odd going on there. |
|
I've installed nu from main, i.e. |
|
let's close this if the problem doesn't exist any longer. thanks! |
|
Issue still presents if linebreak characters ( |
|
I'm not sure how to reproduce this. Do I need to change my right prompt to something special? |
prompt_linebreak.mp4I tested with different escape symbols (win10)
Of course its edge case and i could define function preparing prompt with |
|
Thanks for the information.
|
|
this still exists at win10/wezterm/nu0.67.0 |
|
Yeah I saw it again with my setup and I don't know what to do about it.
…On Fri, 19 Aug 2022, 08:33 zhijia,.zhang, ***@***.***> wrote:
this still exists at win10/wezterm/nu0.67.0
—
Reply to this email directly, view it on GitHub
<#5585 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDVSDNZNMBNVLCFPEFN43VZ4TDVANCNFSM5WLUDRUQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I only notice this on the Windows version of WezTerm. The Mac version works great. Does this still happen with shell_integration set to false in the nushell config.nu? |
it works at |
Setting this to false fixes the issue for me as well - wezterm 20220807-113146-c2fee766, nu 0.67, win 10 |
|
It's sad that WezTerm behaves this way to our ansi escape sequences. I have no idea why it repeats the prompt with every character typed. It's not like we're sending the escape sequences for every character. It only happens around the time the prompt is drawn. |
|
The way that PTYs work on Windows is a bit different from unix systems. What I suspect may be happening here is that you are tickling an edge case that causes conpty to emit something unexpected that results in the output shown above. Earlier comments indicate that this isn't a wezterm issue and that it manifests in other windows terminals. In wezterm, you can use I would recommend opening an issue at https://github.com/microsoft/terminal to get input from the team that owns ConPTY who can perhaps advise on how to deal with this. |
|
See wez/wezterm#2442 (comment) for an example of how surprising some of the conpty-transformed output can be |
|
@wez Thanks a bunch for chiming in and giving us your perspective!!
We definitely see a pretty serious flicker with Windows Terminal Preview but not in Windows Terminal, nor Alacritty. We have an issue open already here microsoft/terminal#13710. We haven't seen anything as serious as how WezTerm reacts on windows. Out of respect for you, I created this gif to show you what I see in Windows using WezTerm. I'm definitely not trying to lay this problem at your feet for fixing and running away, but I wanted to be clear about what I see as it's a little bit different than what is posted above. While I haven't tried every possible Windows terminal software, my usual test scenarios include Windows Terminal (sometimes preview too), Alacritty, and WezTerm. PS. Can someone please test Wez's suggestion with |
|
Please capture a terminal recording:
The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using The terminal recording allows me to replicate what is being sent to the terminal without requiring me to install the same applications as you and replicate your configuration for everything. It would be great to get one capture on Windows and another on a unix system so we can compare what wezterm is seeing. |
|
I mentioned this over at #6214, but: Setting "shell_integration: false" in config.nu fixes the problem (tested on alacritty, wezterm, and Windows Terminal) |
|
@wez Here's one from my m1 MacBookPro |
|
If you If I reduce the cast to just one of the lines that is causing problems: and run it's a little bit easier to see that after printing the If you look at an equivalent line from the macOS output: and you can see that the stream uses cursor position escapes along with escapes to save/restore the cursor position. |
|
If I edit the macos capture and remove the It looks to me as though this is a ConPTY issue where unexpected/unknown OSC sequences confuse it about cursor positioning or some other similar concern that triggers it to rewrite the output stream. A workaround would be to skip outputting OSC 133 on Windows or if you know that ConPTY is present. |
|
@wez That matches with what we're seeing. If people turn off shell_integration in nushell this behavior doesn't show up in WezTerm. However, if we remove |
|
Just wanted to chime in to confirm I still get this with v 0.78.0 of nushell and wezterm 20230408 (69ae472) |
|
Is it possible for now to disable |
well, I know wezterm will set certain environment variables prefixed with |
|
Linked issue of microsoft/terminal has been fixed - microsoft/terminal#13710 |
|
anyone built windows terminal to see if it's fixed? i'm not brave enough right now. hopefully we'll get a new WT version soon. |
One way to do this is to edit So that shell_integration is disabled when nushell is loaded by WezTerm. |
|
I wanted to note that wezterm's nightly build has included the upstream conpty fixes for the past week or so. |
|
Thanks for that! Hopefully this can be closed soon. I love both wezterm and
nushell
…On Sun, 4 Jun 2023, 15.15 Wez Furlong, ***@***.***> wrote:
I wanted to note that wezterm's nightly build has included the upstream
conpty fixes for the past week or so.
—
Reply to this email directly, view it on GitHub
<#5585 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDVSGGB3QYTF6OCMSMAL3XJSC6FANCNFSM5WLUDRUQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@wez I tested your upstream fixes and tagged you in my testing report on the WT thread. WezTerm still looked broken to me but in a slightly different way. |
sholderbach
added
line editor
|
0.82 still had this issue. But 0.84 doesn't seem to have it 🙌 I think I can finally switch to |
|
I don't believe this issue is fixed. It's just that we changed the default of This is from 20230712-072601-f4abf8fd |
I think the root cause has not been precisely indentified. I would guess it's likely due to quirks in the windows pseudo terminal API implementation, as this behavior doesn't only show up for wezterm, but some other terminal emulators on windows too. that being said, there's almost certainly something unusual in this behavior is very strange, but I think it might be related to this issue, so I'll describe it here in case it might help to locate the root cause of the problem. initially, the shell seems work normally, but after several commands, once the screen begins to scroll up, then each key stroke will make the screen scroll one line. please note, I have set |
|
My guess for this has always been that reedline is redrawing the prompt on every keystroke. I think this could be something that was left behind when we had a ticking clock as a prompt. It's kind of tricky to diagnose and fix but I'm hoping someone will dig in and figure it out. |
|
Hey, just commenting here to come and say that I have the same issue that OP is talking about and it is still happening even on a nightly version of wezterm. Thanks! |
|
Are you sometimes —but not when this duplication error is happening — using tmux? Does it echo normally when using tmux? |
Unfortunately I am not tmux, since I am on windows. So this is just normal wezterm. |
|
Hi It seems that changing shell_integration: {
# osc2 abbreviates the path if in the home_dir, sets the tab/window title, shows the running command in the tab/window title
osc2: true
# osc7 is a way to communicate the path to the terminal, this is helpful for spawning new tabs in the same directory
osc7: true
# osc8 is also implemented as the deprecated setting ls.show_clickable_links, it shows clickable links in ls output if your terminal supports it. show_clickable_links is deprecated in favor of osc8
osc8: true
# osc9_9 is from ConEmu and is starting to get wider support. It's similar to osc7 in that it communicates the path to the terminal
osc9_9: true
# osc133 is several escapes invented by Final Term which include the supported ones below.
# 133;A - Mark prompt start
# 133;B - Mark prompt end
# 133;C - Mark pre-execution
# 133;D;exit - Mark execution finished with exit code
# This is used to enable terminals to know where the prompt is, the command is, where the command finishes, and where the output of the command is
osc133: false
# osc633 is closely related to osc133 but only exists in visual studio code (vscode) and supports their shell integration features
# 633;A - Mark prompt start
# 633;B - Mark prompt end
# 633;C - Mark pre-execution
# 633;D;exit - Mark execution finished with exit code
# 633;E - NOT IMPLEMENTED - Explicitly set the command line with an optional nonce
# 633;P;Cwd=<path> - Mark the current working directory and communicate it to the terminal
# and also helps with the run recent menu in vscode
osc633: true
# reset_application_mode is escape \x1b[?1l and was added to help ssh work better
reset_application_mode: true
} |
Resolves Wezterm on Windows: <nushell/nushell#5585>
|
This might be a duplicate of #10671 (for which making osc133 false also fixes it) |
|
Hi, I'm currently trying out nushell and I am also running into this problem. Not only does previous output scroll up one line on each character modified in the input line, but also when navigating around in the input line. Just pressing the left and right arrows is enough, even on an empty line. However I have a hunch what the reason might be: Nushell's prompt emits Some context: I also only recently started trying out nushell and wezterm. My previous shell is fish with vi key bindings and I manually added the |
|
Thanks for the advice @kmoschcau. I'll look into your findings to see if we can somehow do that for nushell too. For now, if you turn off osc133 in your config, the problem should go away. |
|
From what I can tell OSC 133;A is the first character on the line but it's repeated a few times for some reason. |
|
I definitely think something strange is going on with WezTerm. Both these tests did the same thing which is cargo run and then hit enter. Windows Terminal
WezTerm
|
|
Sure wezterm is the only one I have seen so far that is adhering to the spec so strictly. But nushell is also the only shell that I tried, which provokes this behavior in WezTerm. Neither powershell nor fish do this. Granted, I emit |
Describe the bug
Every keystroke duplicates the prompt line for no reason.
See wez/wezterm#1999.
I had to post a bug here, as I'm beginning to think that this is
very much tied to nushell and not the
wezterm(or atleast both).How to reproduce
Nothing but type in your terminal and see the prompt replicate.
Expected behavior
I don't expect the terminal to fill up with the line before the keystroke.
Screenshots
No response
Configuration
Additional context
I'm on Windows. I tried with nightly wezterm, latest stable of nu, with no configuration in wezterm, and with default configuration for nushell; We also tried to no configuration files for nushell.
The text was updated successfully, but these errors were encountered: