Input Editor: Prompt: Support a fully customizable prompt (and/or honor PS1)

[zachlloyd]

Right now we make our best guess at a useful default prompt, but don't support any customization.

The likely path forward is for us to put a nicer UI on prompt customizability and support generally useful prompt features like git status.

Another option would be to fall-back to PS1 for prompt rendering, but that would mean we'd need to support a full terminal grid in the prompt section of the input. I think we would probably only do this as a fallback, not the primary customization method.

[m50]

It looks like you use starship for the prompt? Could be wrong on this.

If so, utilize the starship configuration (~/.config/starship.toml) when rendering starship, because that's an easy win for prompt customization, easier than supporting a full custom PS1.

[zachlloyd]

We don't use starship, but using the configuration (or at least being compatible with it) is an interesting idea. Thank you for suggesting it!

…

On Wed, Aug 25, 2021 at 9:19 AM Marisa ***@***.***> wrote: It looks like you use starship for the prompt? Could be wrong on this. If so, utilize the starship configuration (~/.config/starship.toml) when rendering starship, because that's an easy win for prompt customization, easier than supporting a full custom PS1. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSUZN3Z7PVSSUH5ZDAKOLT6TUW5ANCNFSM5BRR7BDA> .

[TreTuna]

Custom prompt is something that I'm definitely missing a lot with Warp right now. The primary ones I've been using as of late have been Powerlevel10k and Starship (which has been taking over my prompts on most machines as of late). I would agree with @m50 here that just having Starship and using the customization from that would be amazing.

[lrvdijk]

Another point: I often use Conda (python) environments, and when you activate one, it often updates the prompt to show that it's active. Currently there's no indication of any active conda environment after conda activate your-env.

[anicholson-sq]

Yeah, not seeing the PROMPT I was expecting (also Starship) was rather jarring. It made me wonder what else from my .zshrc was being ignored/overridden.

[kaihoffman]

I also would absolutely need things from my bash PS1 to show to feel I could use Warp fully, namely my git branch and current Kubernetes context. These are currently set by scripts that show as part of the bash PS1

[zachlloyd]

@gagata is starting to explore solutions here. Would love all of your input as we spec things out.

[lak]

I'm also finding it jarring not to have my prompt. There's a lot of info in my prompt that isn't in this one.

It's especially useless because I don't even know what's in this prompt. Do the colors mean anything? I don't know. What systems are supported and which aren't? I don't know. The only real mention of the prompt in the docs is that you don't support PROMPT_COMMAND, and there's no mention of PS1.

[elviskahoro]

Hopefully this quarter!

[adamshaylor]

The only thing I need out of a custom prompt beyond git info is some language/framework compatibility info. That’s the only reason I still use Starship. I don’t even use the nerd fonts, which hack a proliferation of ephemeral technology icons into some ostensibly less used Unicode characters. The output cannot be rendered anywhere without that font. Plaintext output is perfectly adequate. Here’s what my Starship prompt looks like:

Perhaps a custom prompt isn’t needed at all. Warp is more than just a prompt. This compatibility info could live somewhere else in the UI, e.g. the footer like in VS Code. Its visibility could even be toggled by the user.

My point is, custom prompts are historically a first recourse for plugging holes in terminal functionality. Beyond git and language/framework info, what else do people need to know? Googling around for custom prompts, it seems like it boils down to knowing who you are (username) and where you are (directory, git status, host name/address). Why turn the prompt into a junk drawer of missing features when Warp could actually add them natively?

My input is just one anecdote, so take it with a grain of salt. I appreciate the work everyone is doing here. Terminals have been stuck decades behind modern code editors in terms of ease of use and productivity (unless you’re unusually well versed in POSIX and shell scripting). Warp is bringing the terminal into the modern age. Thank you.

[zachlloyd]

I agree with this analysis @adamshaylor - thank you for sharing. We are trying to think through what the prompt should be from this perspective, but also balancing people's existing workflows and muscle memory.

[kaihoffman]

Beyond git and language/framework info, what else do people need to know?

Kubernetes contexts. Because they are very powerful.

[elviskahoro]

@lrvdijk - see:

• Integration: can not use conda #235

It's coming out this wednesday!

[elviskahoro]

@TreTuna @m50 @anicholson-sq Are yall in the Discord? We started speccing prompts this week and will be sharing design mockups there.
Are you watching @adamshaylor's starship issue:

• Moved to discussion #422: Support or supplant Starship modules #247

[ccpost]

I agree with @adamshaylor that Warp is an opportunity to start re-thinking the prompt as the main mechanism for showing status. I find that if I start putting everything I want to see in the prompt, it quickly becomes large and hard to parse visually. I'd love to see some basic status bar functionality as an additional choice.

That said, there is one important case where the prompt is a win over status bar widgets: historical context. Status bar widgets (at least how they exist in iTerm) only show the current state, but the prompt persists in your scrollback and can give you useful information about the context in which a command was run.

As it exists today, that would be the deciding factor for me on what to put in prompt vs a status bar. Though: maybe status bar widgets could optionally persist into scrollback? 😉

EDIT: Changed some phrasing to make the meaning clearer. (cc @lak)

[lak]

I quite like the idea of building other mechanisms for providing information to the user outside of the prompt.

But I caution you against language like "dumping ground for every possible status". That trivializes how and why people customize their prompt.

The actual critical bit is the customization.

You could have an amazing prompt, or an amazing status line that obsoletes putting information in the prompt.

But if I can't customize it to show what I want to see, then it's still less useful than a less powerful but more tunable solution.

Just take the difference between how a sysadmin (my background) and a dev (where I spent a long time) would tend to set up their prompts. Or the difference between a minimalist and maximalist. I've employed devs in the past who would not use color, for example, while I rely heavily on it.

If you pick what's shown and don't allow customization, then you're cutting out a lot of what works for other people.

I expect you know this, and other discussion is making it clear you do see the value in customization. I was just put off by the language a bit, and wanted to clarify what I really care about (customization, vs any given feature).

[CamJN]

I for one am not interested in wasting additional screen real estate with a status bar, the prompt has to be rendered so that space is already used, so that's where information should go.

[elviskahoro]

@CamJN my initial opposition to this is split panes and subshells. Similarly to how TMUX has a status bar that gives global information as opposed to pane / session specific information.

But who's to say we can't figure out something that's even more effective at communicating important information from a global standpoint. I think the problem that status bars initially addressed was out of sync information for a particular pane or window (after context changed) but this may not actually be an issue for Warp given that it's native. Just my 2 cents

@ccpost any feedback on this too, I know you've been contributing feedback for months + wrote the status bar issue

[ccpost]

@elviskahoro Very good point on split panes; that certainly adds more cases to think about. Definitely putting something in the prompt will make it visible always (even if the pane isn't active), which may be desirable or not depending on the use case.

I had also not considered tmux's global status bar. iTerm's status bar (which I'm most familiar with) has a single status bar across all panes, but it runs in the context of the current active pane, so it changes when you switch panes.

I think the problem that status bars initially addressed was out of sync information for a particular pane or window (after context changed) but this may not actually be an issue for Warp given that it's native.

Do you mean that you're potentially considering a model for Warp where the prompt is able to update at any time instead of on a new command? That could definitely cover some status bar use cases, though it might feel a bit too surprising coming from any other terminal.

Stepping back for a second: anything I can think of to put in either a prompt or status bar boils down to some sort of state that could be shared or not across various levels (shell session / directory / virtualenv / conda env / user / machine / etc). That's why I tend to think of the prompt + status bar as pretty similar with slightly different behavior and visual layout. I'm certainly missing things, so I'd be interested to hear prompt use cases that don't really fit into that mental model.

Thinking purely along the state / context use cases, some questions I would ask myself for each piece of info to determine where I'd ideally want to see it visible (either in prompt or otherwise):

• Is it global to my entire machine? -> If so I probably don't want it duplicated across panes.
• Is it scoped to the CWD and both panes are in the same CWD? -> Probably don't want it duplicated across panes.
• Is it scoped to the shell session but a minor detail (ex: PID of the shell)? -> Probably want it to only show for the active pane.
• Is it scoped to the shell session but business-critical (ex: the active AWS_PROFILE operating on production) -> Probably want to always show it.
• Is it only relevant to now (ex: remote CI status)? -> Don't want it to propagate into the scrollback.
• Is it useful for context on historical commands (ex: Git branch)? -> Want to see it for each command in the scrollback.

There is probably more, but I hope some of these might be useful for brainstorming.