Unable to move cursor back to second line after latest update (using Starship)

[onecrayon]

Dupe Check

• [X] I have searched Warp bugs and there are no duplicates

Describe the bug

The latest update introduced cursors on the same line as the prompt, which I hate. I'm using a custom cursor, though, so I figured I would just follow the recommended way to adjust to a second line, but it doesn't work.

To reproduce

1. Install Starship
2. Configure prompt to use Starship with the Warp-recommended follow-up to overwrite the PS1 in ~/.bash_profile:

   eval "$(starship init bash)"
   PS1="${PS1}"$'\\n'

3. Restart Warp and the cursor is still on the same line as the Starship prompt

Expected behavior

There should be a single setting for Warp-provided prompts for same-line cursors that also applies to custom prompts. Maybe Starship is doing something funky, but it's bizarre to me that before Warp just always stuck the cursor on a new line and now it always sticks it on the same line without being able to adjust the behavior in the app.

Screenshots

No response

Operating system

MacOS

Operating system and version

14.2

Shell Version

bash 5.2.15(1)

Current Warp version

v0.2024.06.18.08.02.stable_03

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[Advait-M]

Hey @onecrayon

Thanks for reporting this!

So, first off - to address how to return to the prior state:

• The provided command generally applied to "vanilla" prompts rather than custom prompt plugins, such as Starship, which generally have their own configurations.
• I checked the command myself against Zsh and Bash's Starship. Verified it actually does work in Zsh, however, it does not work in Bash (due to differences in how the shells pass around their prompts I believe). This command was largely meant to tackle the "simple prompt" case of something like PS1="foo".
• Could you please provide your starship.toml? I can help with modifying it to revert to the previous behavior. More generally, add_newline is the Starship config option for adding a newline or not (see https://starship.rs/config/#options). Feel free to let me know if you'd like to email it to me instead and I can follow up with that (to avoid posting here)!

With respect to Warp's updating behavior:

• The behavior for PS1s within Warp was actually a broken experience. We were not respecting user's custom prompts. We were artificially adding a "newline" at the end of their prompts in Warp.
• We've received a lot of feedback about this being an issue at #2304.
• Hence, we'd made the decision to fix this behavior within Warp and truly respect your PS1/custom prompt. However, we wanted to make it easy for folks to revert their experience if they'd wanted to, hence offering a command to help (in the simple cases).

Why did we not offer an option within the app to revert the behavior?

This was a major refactor of core Warp code to support this feature. At a high-level, there'd be a lot of product and tech debt for us to maintain a setting like this within Warp. At the end of the day, the existing PS1 experience within Warp was broken, and this is what it should've been from the start. We do realize the friction it causes folks that want to have the legacy experience, hence our efforts to alleviate this.

Also note that we have not changed default Warp prompt (non-PS1) behavior. It still uses 2 lines by default (opt-in experience into same line prompt).

That being said, we really appreciate your feedback here - please keep it coming!

[onecrayon]

@Advait-M The vast majority of my starship.toml is just disabling a bunch of output that I don't want to see, along with custom symbols using a nerd font for some of the formatting for other sub-commands. If you remove all of that, it boils down to just this:

[line_break]
disabled = true

add_newline is true by default, and I didn't override that (plus I would expect this to have no impact either way, because it has to do with adding newlines before the prompt, not after it). However, before filing this issue, I attempted the following:

add_newline = true
format = "$all$line_break"

[line_break]
disabled = false

But this also made no difference. I can verify that the other elements in my TOML file are not interferring, because when I comment them all out and just leave the above options the behavior is identical (the specific prompt contents just change a little bit).

[Advait-M]

@Advait-M The vast majority of my starship.toml is just disabling a bunch of output that I don't want to see, along with custom symbols using a nerd font for some of the formatting for other sub-commands. If you remove all of that, it boils down to just this:

[line_break]
disabled = true

add_newline is true by default, and I didn't override that (plus I would expect this to have no impact either way, because it has to do with adding newlines before the prompt, not after it). However, before filing this issue, I attempted the following:

add_newline = true
format = "$all$line_break"

[line_break]
disabled = false

But this also made no difference. I can verify that the other elements in my TOML file are not interferring, because when I comment them all out and just leave the above options the behavior is identical (the specific prompt contents just change a little bit).

Thanks for the info! Got it - agreed re add_newline. Yep, so line_break affects this:

Default state - just $all (or with line_break set to disabled = false):

$all with line_break set to disabled = true:

I believe the top version is what you desire for a 2 line prompt? Let me know if I'm wrong here (with regards to the goal state) or I missed something!

[onecrayon]

@Advait-M Found it! Apparently if you disable the character module, then it doesn't matter if your line_break module is enabled or not; it will never output a linebreak. I'm not too sure what is going on there since those two should be inter-related based on their documentation, but this looks like something that deserves to be filed in the Starship issues rather than here.

[Advait-M]

@Advait-M Found it! Apparently if you disable the character module, then it doesn't matter if your line_break module is enabled or not; it will never output a linebreak. I'm not too sure what is going on there since those two should be inter-related based on their documentation, but this looks like something that deserves to be filed in the Starship issues rather than here.

Ooh interesting - yeah that does sound weird, I wouldn't expect those two to be interconnected 🤔 .

Gotcha - agreed! Thanks for digging into this!

And again, thanks for raising this! I'll explore how to make the onboarding block that we show to Warp users better for Starship users on Bash too - want to make sure we can make it as easy as possible to go back to the previous experience, if users would like to! 😄

[Advait-M]

^ We're gonna try to improve the SLP onboarding block to specifically detect/target plugins such as Starship and p10k (with specific instructions) hence the re-open above! 😄