prompt: default prompt colors to the terminal foreground

[iniw]

#992 reset stale sgr state before each repaint, which fixed prompt color bleed from previous command output. it did not fix the starship case reported in starship/starship#6560 and nushell/nushell#16384 because reedline still applied its own default prompt colors immediately before printing the prompt.

that meant a prompt implementation that returned ansi text without overriding get_prompt_color() still inherited reedline's defaults. for starship, style = "none" emits no color sequence at all, so the first visible character inherited reedline's green prompt color instead of the terminal's foreground color.

this patch changes the default prompt, multiline, indicator, and right-prompt colors to the terminal defaults. prompts that want explicit colors can still override the color methods, but unstyled prompts now stay unstyled and no longer need an extra reset sequence to avoid the green first character.

[fdncred]

We've covered this in the past. If we set these to none then there are no colors for the prompt at all for reedline users unless you're using something else to color your prompt.

[iniw]

i don't think you're right (but i'm not fully sure either!). AFAIK emitting text without a color (which is the case in this patch) will just default to the terminal's foreground color, right? so the actual color of the prompt will depend on the user's terminal emulator

what i mean is that there will be colors, it just won't be controlled by reedline

[fdncred]

This is what I'm talking about. I really don't want to lose the default coloring in reedline.

Before this PR

After this PR

[iniw]

i understand where you're coming from but i see it the other way around:

users of reedline (including the examples) should override the get_*_color family of functions in the Prompt trait to achieve their desired styling.
reedline, by default, shouldn't impose a particular style on the prompt. it's too low-level for that.

this is just my personal opinion, of course :)

do you think me making the examples colorful again (by overriding the colors) but keeping the default color-less would be a good middle ground?

[fdncred]

do you think me making the examples colorful again (by overriding the colors) but keeping the default color-less would be a good middle ground?

maybe. i also wonder if we'd need to do this too in nushell when running nu -n

[iniw]

okay, I've made the DefaultPrompt impl use the old styles. lmk if this is more acceptable now

[fdncred]

I think it's good. Can you look into what changes are needed in nushell to support this?

[iniw]

Can you look into what changes are needed in nushell to support this?

I implemented this for nushell and have conflicting thoughts about it now. The more I wrote the more I thought that this fix was happening in the wrong place. Regardless of whether or not reedline has a default prompt color, nushell will still have one, so this fix by itself ends up being pointless.

What I ended up doing was checking whether or not a custom prompt string was set or not (which is easy since nushell represents these as Option<String> values), but I don't think this is particularly good since it doesn't sound intuitive for the user to have your prompt colors change based on whether or not you have a custom prompt.

After thinking about it for a bit I think this should be fixed on starship's side.

What do you think? I assume you agree, but I'll wait to read your thoughts before closing this and submitting the starship PR.

[fdncred]

I think you should be able to use nushell, oh-my-posh, starship, others to change your prompt and reedline should care that you do that.

[iniw]

So you think it's ok to change the prompt color based on whether you have a custom prompt or not? If that's alright then I'm happy to implement that.