Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spice up default prompt #6375

Closed
faho opened this issue Nov 30, 2019 · 17 comments
Closed

Spice up default prompt #6375

faho opened this issue Nov 30, 2019 · 17 comments

Comments

@faho
Copy link
Member

@faho faho commented Nov 30, 2019

So our default prompt is

Screenshot_20191130_165715

a simple "user@host prompt_pwd >".

I'd like to spice this thing up a bit. In particular I would like to add:

  • Vcs integration

  • Only displaying user@host if we detect SSH or a VM (via systemd-detect-virt or whatever)

The latter especially is most useful if it is part of the default, because that way you can have no hostname on your home machine and hostnames on remote machines, without having to configure any of them.

And whatever else anyone can think of. The idea here is that we offer a nice experience out of the box.

@faho faho added this to the fish-future milestone Nov 30, 2019
@ammgws
Copy link
Contributor

@ammgws ammgws commented Dec 1, 2019

  • Change (part of) prompt colour or display exit code if it was non-zero.
  • Duration of last command (maybe in fish_right_prompt)?

@faho
Copy link
Member Author

@faho faho commented Dec 1, 2019

So basically what I'd do is first replace the normal prompt with the classic+vcs one, and then add some more stuff on top.

I don't want to go too overboard with it - no right prompt because that has issues with enough terminals, no super-fancy unicode chars (maybe an arrow?), no powerline or anything that takes too long or has too many deps.

The goal is to have a pleasant prompt with some bells that runs fast while giving you some good information, and written in a readable manner so it can also teach the user how they can modify it.

Displaying a failing exit code is a good idea, which the classic+vcs prompt already incorporates (even a fancy pipestatus version!).

@faho
Copy link
Member Author

@faho faho commented Dec 7, 2019

Only displaying user@host if we detect SSH or a VM (via systemd-detect-virt or whatever)

So that "or whatever" was a tad optimistic, because, while there are a few other things to check, including

  • /proc/cpuinfo
  • /etc/debian_chroot
  • dmidecode
  • /sys/devices/virtual/dmi/id/product_name

most of what I can find is at least specific to linux, most of which is already covered by systemd-detect-virt.

So we'd ship a prompt that only shows the host if somebody is running via SSH or a guest OS with systemd on it, iff the vm isn't trying to hide.

While I still believe the host is, most of the time, a waste of space, I'm not sure that's enough.

So let's just switch to classic+vcs now and see if we can add anything more later.

@zanchey zanchey removed this from the fish-future milestone Dec 7, 2019
@zanchey zanchey added this to the fish 3.1.0 milestone Dec 7, 2019
@zanchey zanchey removed the RFC label Dec 7, 2019
@ammgws
Copy link
Contributor

@ammgws ammgws commented Dec 7, 2019

At least for SSH, displaying the host when remoted in would be a lifesaver as I install fish on all my machines/servers/VMs/containers and mainly access them via SSH. Having the prompt show the host by default would reduce the chance of running a unintended command somewhere it shouldn't be run.

@faho
Copy link
Member Author

@faho faho commented Dec 8, 2019

The prompt does show the host by default, this was about not showing it for the simple case of running fish locally as the normal user.

@ammgws
Copy link
Contributor

@ammgws ammgws commented Dec 8, 2019

Ah sorry, I meant something that stands out more:
Screenshot_20191208_191732

@faho
Copy link
Member Author

@faho faho commented Dec 8, 2019

We could add an indication that it's ssh or a vm/container or something. That way it's less critical if we miss something, because you still see the user/host.

I think I'd just go with a prefix? "SSH:" if it's via ssh?

@exploide
Copy link
Contributor

@exploide exploide commented Dec 8, 2019

You mean like the first one? I tried a few variations:

SSH: user@host ~>

ssh: user@host ~>

[SSH] user@host ~>

[ssh] user@host ~>

(ssh) user@host ~>

Personally, I find the last two most appealing. Lower case looks less hefty and goes nice with (also often lower case) username and host. And braces look a bit cooler than the colon.

faho added a commit to faho/fish-shell that referenced this issue Dec 8, 2019
This is a description of whether we're connected over ssh or in a
container or something.

It's used to signal to the user that this
particular terminal is "special", and not on the local machine, e.g.
to avoid mistakes like executing `poweroff` on a server instead of
your development laptop.

Unfortunately this (at least currently) isn't dependable enough
to *disable* display of the user@host part on "normal" machines, but
we can add something on ssh.

See fish-shell#6375.
@mqudsi
Copy link
Contributor

@mqudsi mqudsi commented Dec 9, 2019

imho I prefer classic as the default and would rather hear from more people before shipping this change. fish is not (only) a developer's shell and developers know how to enable (or search) for VCS integration if they want it; moreover git is horribly slow and our lack of async support means this is going to cause some problems.

On a 64GB 1950x I still have to wait 10-30s for a simple git status to run in the Linux or FreeBSD kernel directories.

@faho
Copy link
Member Author

@faho faho commented Dec 9, 2019

That logic goes both ways: If you're working on the kernel you also know how to disable the vcs prompt. Also are you sure you've not turned on the "informative" prompt? That thing is quite the time sink.

IMHO vcs prompt info is too useful to relegate to an option somewhere.

@krobelus
Copy link
Member

@krobelus krobelus commented Dec 9, 2019

I think the default prompt should never be slow in realistic situations (large repositories, filesystems served from network). The current one seems to be fast enough, potentially much faster than git status since it only shows branch status, (unless configured with $__fish_git_* or git config bash.show*)

@mqudsi
Copy link
Contributor

@mqudsi mqudsi commented Dec 10, 2019

I just checked and in the interest of fairness, the plain vcs prompt is more responsive than I recall it being. I still prefer the classic as a default for most users, though, and here's why (writing up as I try it for the first time):

  • The prompt is longer, 50 characters after executing a random command in a git directory as compared to 30 before, taking up a bunch of space and triggering a fish bug (when the window size is less than x width, on wrap the entire first line is cleared).
  • The prompt is confusing. (master) is clear enough, but what does [64|1] mean? modified vs unstaged? commits ahead or behind master? files staged? files unstaged?
  • image
  • Even if the meaning of [64|1] (in my case) were clear, it is of questionable added benefit. What's the point of knowing how many files are changed if I don't know what they are and so I need to run git status to find out, anyway?
  • Never mind, the prompt just changed on its own again... Oh, I get it. It's the pipeline status and has nothing to do with git!
  • [64 | 1] is therefore clearly the pipeline status, command one exited with code 64, command two exited with code 1... but then what's the point of repeating the [1] again showing me the total exit code?
  • It is unfriendly: the length of the prompt keeps changing, meaning
  • my commands no longer line up.
  • I can't scan the prompt up and down quickly to find something I entered before because I no longer know where to look.
  • It has too many spaces and too many symbols, it's very hard to see where the prompt ends and where the commands begin

That aside, @faho, is the colorizing of the username intentional? I went from
image

to

image

I have four colors in my prompt now, including two shades of green. I have five colors in my prompt, including two shades of green and two shades of yellow. Perhaps this is just a Christmas-themed special 😉. (I would petition to remove the username altogether rather than make it even more prominent.)

@faho
Copy link
Member Author

@faho faho commented Dec 10, 2019

That aside, @faho, is the colorizing of the username intentional? I went from

It's been that way since 2.2.0 at least, so yes.

[64 | 1] is therefore clearly the pipeline status, command one exited with code 64, command two exited with code 1... but then what's the point of repeating the [1] again showing me the total exit code?

Okay, yeah, that does add both status, but only if the last command also fails. That's too much.

It is unfriendly: the length of the prompt keeps changing, meaning my commands no longer line up.

That can't really be a goal generally, as that will also happen when you cd.

krobelus added a commit that referenced this issue Dec 11, 2019
If a command fails, print the pipestatus in red instead of yellow and
don't print the status of the last process again. See #6375.

Also use $fish_color_status for coloring status consistently.

Also use __fish_pipestatus_with_signal to print SIGPIPE instead
of a numeric code on e.g.: yes | less +q

[ci skip]
@krobelus
Copy link
Member

@krobelus krobelus commented Dec 11, 2019

The username color feels weird, I'd say make it $fish_color_normal.
Removing the username might be possible, I don't know (the prompt for root looks clearly distinct even without the username).

The pipestatus can be useful to communicate why a pipeline has failed.
However, as shown by the pbpaste example, it's not really obvious what's going on.

I pushed 6902459 to get rid of the duplicated exit code and the yellow coloring. It also converts some exit codes to corresponding signals: run git log and press q; this should show a [SIGPIPE] status instead of a number - which might still be confusing, because from the user's POV, the command has not failed...

If we want to maintain the length of the prompt, then we should probably not print the exit status, but only color some parts red to indicate failure.

Edit: If we stick with this pipestatus, I think we should special-case jobs that produce SIGPIPE (13) to not print this error status. Consider for example yes | head.

@krobelus
Copy link
Member

@krobelus krobelus commented Dec 11, 2019

That aside, @faho, is the colorizing of the username intentional? I went from

It's been that way since 2.2.0 at least, so yes.

The change from the previous default (no color for the user) is because only the prompts classic_vcs and terlar respect $fish_color_user

Ignoring SIGPIPE in cc7ae03 for now.

faho added a commit to faho/fish-shell that referenced this issue Dec 11, 2019
This is a description of whether we're connected over ssh or in a
container or something.

It's used to signal to the user that this
particular terminal is "special", and not on the local machine, e.g.
to avoid mistakes like executing `poweroff` on a server instead of
your development laptop.

Unfortunately this (at least currently) isn't dependable enough
to *disable* display of the user@host part on "normal" machines, but
we can add something on ssh.

See fish-shell#6375.
@exploide
Copy link
Contributor

@exploide exploide commented Dec 11, 2019

+1 for simplifying the exit code indication

-1 for removing the username

I think the username is one of the most important things shown by a prompt. Even if normal user and root can be differentiated via colors, that would not feel save enough to me and I would constantly run whoami. Besides, when switching between normal users via su or sudo -u, this information is really helpful. Not to mention logging in remotely via ssh with whatever username.

@krobelus
Copy link
Member

@krobelus krobelus commented Dec 11, 2019

Yeah, username seems essential.
We could reset $fish_color_user to normal in __fish_init_3_1_0, that'd be less cheesy than the current one with #6398:
image

faho added a commit that referenced this issue Dec 30, 2019
This is part of our (well, my) quest to spice up the default prompt.

In this case we color the host if $SSH_TTY is set, which is easy to
detect and helps draw attention to the host.

See #6398.
See #6375.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants