Cursor flashing / teleporting on typing in a nushell prompt on windows

[nodomw]

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

wezterm 20221119-145034-49b9839f

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Upon typing in the prompt, the cursor starts teleporting between the end of the line and the cell below the prompt. See gif below

Happens on both stable & nightly

To Reproduce

I'm running nushell with starship, I tried it on cmd with clink and it does not occur. I tested on alacritty and windows terminal. In alacritty there was no issue whatsoever, on wt, there was a different kind of flashing.

I tried replicating the same thing in neovim, did not happen.

Turns out it happens with the default starship config as well.

Configuration

starship.toml wezterm.lua

(github did not let me upload the configuration with a .lua extension)

Expected Behavior

No response

Logs

No response

Anything else?

No response

[wez]

Please capture a terminal recording:

• Launch wezterm. If possible, please use the default terminal size of 80x24 cells as it helps to keep things smaller and easier to manage.
• Inside that terminal run wezterm record to start a recording session.
• Run through your reproduction steps
• Then type exit
• You should see a message like:

*** Finished recording to /var/tmp/wezterm-recording-sF6B3u.cast.txt

• Attach the file that it produced to this issue.

The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using wezterm replay.

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.

[nodomw]

wezterm-recording-Whkdyn.cast.txt

[holly-hacker]

I'm getting something similar using wezterm on windows with the nu shell and default configuration. When I type in nu, every input will cause a new line to be created. I've attached a wezterm record session but it looks like this:

Tested on latest release. If this turns out to be a different bug, I can create a separate issue with more detail and testing.

wezterm-recording-vnYN5M.cast.txt

[ZodiacWind]

I have encountered both two issues, but I cannot replicate the bug with wezterm replay <the record file> . I have not figured out why. Maybe there are some conflictions between nushell and wezterm.

[ZodiacWind]

I think this issule is related to nushell/nushell#5585 and #1999. My current workaround is set shell_integration:false in config.nu for my nushell.

[wez]

Yeah, this sounds like a duplicate of #1999, but let's keep this one open for visibility. The issue is at the intersection of nushell and the windows conpty layer; it is tracked in https://github.com/nushell/nushell/issues/5585 and upstream of that in the conpty layer in https://github.com/microsoft/terminal/issues/13710

[Xenos112]

i see this is a very old issue in here, when will it get fixed cuz i still had the same issue, i tried to open issue here but i found this @wez (sorry for the tag)

[alloc33]

same tho

[gi-b716]

Same question.

[JackTheMico]

For me the current workaround is to set the osc133 to false, which is inside the shell_integration in config.nu

Here's my related part of config.nu

# Starship
$env.config.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
  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
}

After that, start a new nushell and the problem is gone.

[chrisant996]

@wez Hi, I can help track this down. I'm the maintainer of Clink and someone reported this same problem happening in Clink now (after enabling Clink to print Semantic Prompt codes for WezTerm).

I did a bunch of debugging in https://github.com/chrisant996/clink/issues/821 and narrowed it down to a problem in WezTerm's handling of OSC "133;A" ST. I looked at the sources for FreshLine and fresh_line, and WezTerm is clearly trying to correctly handle the fresh-line operation from the Semantic Prompts proposal.

The fact that https://github.com/nushell/nushell/issues/5585 is related is super interesting:

In nushell, the OSC "133;A" ST is printed multiple times within a single "input prompt from the user's perspective" (i.e. they haven't pressed Enter yet).

In https://github.com/chrisant996/clink/issues/821, the OSC "133;A" ST is repeated multiple times because Clink intentionally reprints the prompt during Asynchronous Prompt Filtering (basically: show a temporary prompt, run expensive commands like git status in the background, update the prompt with new information once the background commands finish).

I made a simple text file basic_133a_exercises.txt which I can print via type basic_133a_exercises.txt.

And that revealed some unexpected things:

1. "TEST ONE" malfunctions until the cursor reaches the bottom of the terminal window -- the fresh-line moves the cursor down, but one of the two real newlines after that has no effect. And it's 100% consistent.
2. "TEST ONE" functions correctly after the cursor reaches the bottom of the terminal window.
3. (Trying it in Windows Terminal reveals that Windows Terminal does not implement the fresh-line behavior in "133;A".)

To capture this screenshot, I started with a shorter window, ran type twice (first malfunctions, second functions correctly), and then I made the window tall enough to show both in a single screenshot. My goal was to have a screenshot that demonstrates the malfunction occurring in plain cmd.exe, without Clink or Nushell involved at all.

But the weirdest part is the "teleporting" behavior. It happened in nushell, and it happens in Clink as well. Once the cursor moves down an extra line when it shouldn't have, then certain interactions will cause the cursor to go back up to where it should have been if nothing had malfunctioned, and other further interactions will make it drop down a line again, and then back up, and so on... BUT only if the cursor was not yet at the bottom of the terminal window! If the cursor was already at the bottom of the terminal window, then the cursor remains stuck one line down from where it should have been, until the user starts a new input prompt.

While the results look "random" and "unpredictable", I don't believe that's the case at all: they are 100% consistently reproducible. The same actions in the same order always cause the same results. But there are two different 100% reproducible patterns -- depending on whether the cursor had reached the bottom of the terminal window yet.

So, I think the "TEST ONE" malfunction could be instrumental in tracking down what's happening.

I can easily repro on demand, and I'm happy to collect additional information. Let me know what you need.

[wez]

@chrisant996 interesting! I don't currently have a functional windows dev environment, so I can't reasonably try looking at this directly any time soon.

This is what I see when I cat your test file on Linux:

which as far as I can tell shows that wezterm is behaving correctly in its core logic.

There are two main areas where behavior diverges on windows:

1. conpty sits between wezterm and the data stream, and has a history of mangling/editorializing sequences that it doesn't understand. It could well be that this is happening here. Wezterm cannot influence what happens in that layer, as it is upstream of wezterm.
2. The screen resizing/rewrapping logic is a little different under windows. I wouldn't expect it to factor in here in a fresh terminal window. But, I wouldn't rule anything out.

Are you running a recent nightly build of wezterm? That ships with a newer version of conpty than the last tagged release, which is getting rather old at the moment.

[chrisant996]

I installed the latest tagged release. I'll try a nightly build...

[chrisant996]

@wez Confirmed! Nightly 20251123 does not reproduce the teleporting cursor problem. 🚀

After a new official version of WezTerm is published with the newer conpty, then I can update Clink to send shell terminal integration codes to WezTerm. (I realize that might be a while, I'm just committing that after it happens, I'll update Clink accordingly.)