Fish-shell: Prompt changes to ">" when fish thinks it's too long

[paulmillr]

Fish 2.0.0. When I cd some directories, my prompt (robbyrussell + small changes) becomes stupid (it has nothing to do with git or with $var in cd, I checked).

[ridiculousfish]

This happens deliberately if the prompt is too wide to fit on the screen. Is that what's going on here?

[xfix]

I assume so. The width of shell is 50. The prompt would take 24 characters (if I read it correctly), but it could take way more if read-components is git repository (and this looks like a Node.js package, so it's a possibility). git:master takes 11 characters, so the prompt uses 35 characters (unless of course, it isn't actually master).

Except that doesn't make sense. If the prompt has 35 characters, why it would be too long? I've tried using the prompt he used myself, but I don't see anything wrong.

[rgieseke]

Is there a way (or example prompts) to handle this in a "responsive" way, e.g. don't display machine info if the prompt is too wide or shorten the directory path to the most significant part?

[xfix]

@rgieseke: Sure, check $COLUMNS variable. It's somewhat difficult to do it, but it's possible (you may want to check length of variables with echo -n $var | wc -c for responsive prompts).

[JoshCheek]

This has been an issue for me, too. Personally, I'd rather it wrap my prompt or truncate it or give me the option to override this default prompt. The ">" is really rough for me, I have an emotional dependency on a coloured prompt, and possibly also on seeing the cwd. Without that, I feel lost.

[wwwjfy]

That bothers me, too. I've asked in mail list, no sequential follow-ups though.

I looked up the commit history and found the comment in screen.cpp

    /*
      Ignore prompts wider than the screen - only print a two
      character placeholder...

      It would be cool to truncate the prompt, but because it can
      contain escape sequences, this is harder than you'd think.
    */

I propose that if an env var set (like FISH_WRAP_LONG_LINE), then we skip those lines in screen.cpp to make the prompt "> ".

Something like this.

    env_var_t wrap = env_get_string(L"FISH_WRAP_LONG_LINE");
    if (wrap.missing())
    {
        if (left_prompt_layout.max_line_width >= screen_width)
        {
            /* If we have a multi-line prompt, see if the longest line fits; if not neuter the whole left prompt */
            left_prompt = L"> ";
            left_prompt_width = 2;
        }
    }

    if (left_prompt_width + right_prompt_width >= screen_width)
    {
        /* Nix right_prompt */
        right_prompt = L"";
        right_prompt_width = 0;
    }

    if (wrap.missing())
    {
        if (left_prompt_width + right_prompt_width >= screen_width)
        {
            /* Still doesn't fit, neuter left_prompt */
            left_prompt = L"> ";
            left_prompt_width = 2;
        }
    }

[xfix]

$FISH_WRAP_LONG_LINE won't pass. fish tries to avoid configuration by design, and this reminds me options like "**/ support" in zsh.

[wwwjfy]

@GlitchMr I read the design document, but I don't know what the alternative way is.

Actually, by greping the source code, there are some configurations, including FISHD_SOCKET_DIR, TERM, fish_term256, fish_function_path, FISH_CLIPBOARD_CMD, etc... it's not the whole, but here is the idea.

As the comment I pasted there said, the difficulty is about the escape sequence. I've no experience about that, but I assume long-line wrap is more regular than that. (Or it's quite common just I don't know what it is? Could anyone give an example of that which will cause the problem wrapping)

I myself don't like to use another variable, either. I'll be more than happy to have a better solution to satisfy both.

[zanchey]

On the mailing list, Peter suggests defining a new fish_short_prompt function.

Wrapping the prompt is a possibility; truncating it is where we run into problems with control characters. (e.g. consider truncating a prompt which sets the proxy icon in OS X ala #68).

We would all like to avoid magic variables and new functions (fish_short_prompt, fish_really_short_prompt).

I also think that wrapping lacks elegance, and has the potential to produce pathological scenarios. Consider the case where a user accidentally includes git log instead of git log -n... wrapping would quickly destroy the terminal and possibly make it very difficult to correct the problem. However, at least the cause would be quickly evident, whereas the truncation to > is clearly causing a bit of surprise.

It would be great if we had an example of how to inspect $COLUMNS and alter the prompt accordingly.

[wwwjfy]

@zanchey I don't get it that why git log will make wrapping not work. I tried to include git log in fish_prompt, and made the terminal narrow, and the output was just ugly, but I can see what's that.

By wrapping I mean fish does nothing, leaving it to the terminal, and as my trial to remove the two ifs in my previous post, the terminal can wrap it. No doubt it's not elegant, but a workable version first, then we consider about elegance, right? > was a big surprise, and I've no idea what $PWD is.

I'd like to know a case the wrapping doesn't work. (I'm using iTerm2 under Mac OS X, no idea if iTerm2 has anything special)

Regarding the $COLUMNS, I think we can borrow something from responsive website design to fit different widths.
The rough idea is like

set part1 "what I think cannot be divided"
set part2 "here is part2"
echo -n $part1
if [ (expr length $part1$part2) -gt $COLUMNS ];
    echo
end
echo $part2

Skip the escape sequences.

Even though there will be a function to automatically do the job (The function will be easy to implement), it's still way too complicated for a simple concept.

[ridiculousfish]

Most of the problems associated with wrapping revolve around cursor motion, window resizing, and fish_right_prompt. Wrapping the prompt is probably doable, it's just tricky.

[franciscolourenco]

Truncating would still be more desirable than the arrow in the meanwhile.

[zanchey]

Truncating is actually harder because of control sequences.

[damienmckenna]

Was about to open an issue for this, glad I kept searching.

[johann-koebbe]

Coming to the party late. Sorry.

I ran into this issue the other day, and stupidly tried to figure out what was going on before I searched for it. After wasting a few hours, it finally dawned on me what was going on. _Then_ I searched (facepalm). Anyway, I just updated my fish_prompt function to adjust the directory if the prompt is too long. So far, it looks promising.

Like a lot of people, I put the branch name in the prompt if I'm in a Git repository. Unlike a lot of people, though, I use a two line prompt where prompt line 1 is all the information and prompt line 2 is the "command entry point", so to speak. In my situation, I have to put together the content of pl1 to see if it's too long, and then adjust the directory if necessary. It's kind of cumbersome, but it does work.

  # other stuff happens first, like setting some color variables and things that are irrelevant
  # to this discussion.

  ...

  # get the current dir nicely ... replace $HOME with "~"
  set -l realhome ~
  set -l dir (string replace -r '^'"$realhome"'($|/)' '~$1' $PWD)

  # start with the "full" directory
  set -l pl1 "[$USER] $dir"

  # try to get the current branch
  set -l git_branch (git rev-parse --abbrev-ref HEAD 2> /dev/null)

  if test "$git_branch" != ""
    # we have a branch, so let's add that in
    set pl1 "$pl1 ($git_branch)"
  end

  # get the length
  set -l pl1_len (string length $pl1)

  if test $pl1_len -gt $COLUMNS
    # too long, use the shortened version of dir instead
    set dir (prompt_pwd)
  end

  # we can now build common pieces of the prompt, but because we need to 
  # choose colors based on state, we have to reevaluate some things
  set -l prompt_line_1 '\n%s[%s] %s%s%s'
  set -l prompt_line_1_args "$user_color" $USER "$color_blue" "$dir" "$color_normal"
  set -l prompt_line_2 '%s->%s '
  set -l prompt_line_2_args "$shell_status_color" "$color_normal"

  if test "$git_branch" != ""
    # start by assuming the working dir is dirty
    set -l git_status_color $color_red

    git status | grep clean > /dev/null
    if test $status -eq 0
      # Oh, no changes, so let's use green for the git branch
      set git_status_color $color_green
    end

    set -l git_prompt '%s(%s)%s'
    set -l git_prompt_args "$git_status_color" "$git_branch" "$color_normal"
    set prompt_line_1 "$prompt_line_1 $git_prompt"
    set prompt_line_1_args $prompt_line_1_args $git_prompt_args
  end

  # All together now ...
  set -l prompt_string "$prompt_line_1\n$prompt_line_2"
  set -l prompt_args $prompt_line_1_args $prompt_line_2_args

  printf $prompt_string $prompt_args

I use tmux all day and have been using pane zooming (Prefix z). When zooming in and out, the prompt changes accordingly.

I hope someone finds this useful or could recommend ways to make it better.

[aramiscd]

I use a two line prompt as well. I believe, many people do.

To get arround this issue I put the first line with all the interesting stuff in a function --on-event fish_prompt. This way fish shell will let this line alone no matter what. The second line is the actual prompt. It's just '$ ', and hence just as good as '> '.

Edit:
As a neat side effect, things like virtualenv that prefix your prompt, will prefix the second line.

[JoshCheek]

That's what I do, too. Too hard to track where to look when the location changes across lines.

[christianrondeau]

Adding some (hopefully useful) feedback to this.

I also had "sometimes" the > prompt appearing, and I thought that there was some silent crash in my script for some time. I recently started digging (read: uncomment lines one by one) until I realized prompt_pwd was the one causing this. It's only after trying to dig into the prompt_pwd code that I realized it had nothing to do with this. This was a few hours trying to figure out something that could have been avoided by implementing this differently.

I understand the no-configuration philosophy, but I think here discoverability is one problem, and the other is "ignoring" my prompt by replacing it by another (rule of least surprise).

So here's my idea:

• If you offer customizing fish_prompt, I think you should at least have a fish_short_prompt_character if you're going to fallback to this, and you don't believe in using fish_short_prompt (which I do understand).
• If you are going to fallback to the > prompt, an ugly but friendly solution would be to _tell me about it_. As an example, print fish: could not print prompt, because it is too long.. This way, if I use the default prompt I wouldn't see this, but if I made mine, I'll immediately know what the problem is and what to search for.

Let me know what you think!

[mvolkmann]

@aramiscd, can you post some example code showing how you solved this?

[krader1961]

I'm inclined to agree with @christianrondeau that fish should definitely issue an explanatory message about why the output of fish_prompt is being ignored. On the other hand I don't see the point of something like fish_short_prompt_character. In keeping with historical practice there's really only a couple of reasonable choices: > and $. Allowing the user to select the specific character seems rather pointless. But I do think we should support a fish_short_prompt function as a fallback. If its output is still too long for the current terminal width then fallback to > with a warning message.

[floam]

In keeping with historical practice there's really only a couple of reasonable choices: > and $
I believe we have prompts we ship with fish which use some interesting unicode character for the prompt.

[krader1961]

By "historical practice" I'm talking about shells like the original Bourne shell. And if we're so desperate to display any sort of prompt that we're falling back to displaying a single character prompt it's hard to justify introducing colors and non-ASCII characters.

[christianrondeau]

@krader1961 my thinking was that a "one-character fall back prompt" _is_ a "short prompt" (albeit a very short one). Right now I have to do some crazy string concatenation to check if the prompt does not fit: https://github.com/christianrondeau/dotfiles/blob/master/fish/.config/fish/functions/fish_prompt.fish#L42 - I'd like my prompt on my phone to still be "my" prompt, rather than > if I could.

I think having any way to fall back to anything (be it a short_prompt, single-character prompt config, or even better a built-in way to pass prompt components that support a long and short version, though that's out of the scope of that discussion I think) is the "useful" thing. The "important" thing is to at least know where that came from :)

Since that seems to be an opinionated topic, and I now have a fallback, I'd suggest to "solve" this specific issue with a simple useful message, and all short prompt ideas could become issues on their own. I do believe however that if we include the useful message in the short prompt itself (e.g. Prompt too long\n>), it will be possible for people who _don't_ care about this to easily turn it off.

[floam]

I like the idea of only using the fallback when the actual prompt does not fit. One could check $COLUMNS in fish_prompt and try to provide what they want based on the space available. Fish then would force the fallback only if the prompt author failed to provide their own one that size.

[krader1961]

The exact same thought occurred to me, @floam, while I was walking my dogs. It is trivial for anyone who wants a custom prompt optimized for different screen widths to just do something like this:

function fish_prompt
    if test $COLUMNS > 80
        my_long_fish_prompt
    else if test $COLUMNS > 40
        my_medium_fish_prompt
    else
         my_short_fish_prompt
    end
end

There's no need for fish to directly support alternative prompt functions based on the screen width. So I think the only thing we should do to close this is emit an informative message along the following lines:

The fish_prompt function created a prompt NNN chars wide.
The maximum a CCC wide terminal can display is MMM chars.
>

Maybe add another line that says Type help fish_prompt to learn more.. Yes, that's quite verbose. But it also makes it crystal clear why the user is seeing that unexpected > prompt and provides hints about what to do about it. All in keeping with the "fish: the friendly shell" ethos.

[aramiscd]

@mvolkmann Sure. I'll give a simplified version of my setup.

# ~/.config/fish/functions/fish_prompt.fish
function fish_prompt
  echo -n '$ '
end 

# ~/.config/fish/functions/prompt_prefix.fish
function prompt_prefix --on-event fish_prompt
  echo "this is my prompt prefix line"
end

Finally config.fish contains this line.

prompt_prefix > /dev/null

I think, fish needs to call this function once upon initialization. Otherwise it'll never print the prefix line.
> /dev/null keeps it from printing it twice on startup.

With this setup the prompt will look like that:

this is my prompt prefix line
$

On a narrow terminal it will omit the prefix line and just show the $.

[faho]

I think, fish needs to call this function once upon initialization. Otherwise it'll never print the prefix line.

Note: That's because function files are autoloaded. Before that happens, fish has no idea that your function should be executed on the fish_prompt event.

[hivehand]

@aramiscd, your solution turns out to fix a different problem I’d been having: fzf’s keybindings triggering the full regeneration of multi-line prompts when I really just wanted the regeneration of the last line. Thank you for that!

I ran into some issues specific to my setup: in particular, my prompt_prefix wanted access to some variables that aren't defined until fish_prompt has run once, so I couldn’t run it from config.fish. Also, my initial prompt, upon logging in, consisted of _only_ the last line instead of the full prompt.

I found an approach that resolved both of those issues: conditionally defining and running prompt_prefix from within fish_prompt itself. Applied to your example, it looks like this:

# ~/.config/fish/functions/fish_prompt.fish
function fish_prompt

  if not functions -q prompt_prefix
    function prompt_prefix --on-event fish_prompt
      echo "this is my prompt prefix line"
    end
    prompt_prefix
  end

  echo -n '$ '
end 

This does everything I want, and as a bonus absolves me of needing to make a piped-to-null call of prompt_prefix in config.fish. I’d be curious to hear whether it works for you, too. (I am, incidentally, using fish 2.6.0 under Centos 6.8.0, in case that turns out to matter.) Thanks again for tipping me off to --on-event and its relevance to multi-line prompts!

[wyqydsyq]

@krader1961

On the other hand I don't see the point of something like fish_short_prompt_character

Personally I would like to use the character ➡️ as my "short prompt".

I think there is a perfectly good reason to use a fish_short_prompt function for it, this would allow users who want to use an alternative character to do so, or even have a "fancy" short prompt.

For example I use a powerline-styled prompt:

I would much prefer the prompt retain the styling but hide the branch name and show a shortened path name when displaying a short prompt rather than just getting a basic single-character prompt. If I could specify my own function for short prompts, this would be possible.

[krader1961]

@wyqydsyq, There is nothing stopping you from creating a custom fish_prompt function that examines the $COLUMNS variable and displays a single character, possibly with custom colors, if your terminal width is unreasonably small. Or a shorter, but still informative, prompt if the terminal width is somewhere between unreasonable and reasonable. Note that the proposed fish_short_prompt_character variable does not support coloring that prompt.

Also, how many alternative prompt functions should be supported? And what are the rules by which fish uses one prompt function versus another? This level of customization is something best left to the user via a custom fish_prompt function. The only question is what to do if the output of that function is a prompt that does not fit in the current terminal size. Thus causing fish to fallback to a single character as a last resort to remain usable.

[wyqydsyq]

There is nothing stopping you from creating a custom fish_prompt

Except that from what I can tell has been established in this thread, fish will not use my fish_prompt if it determines that $COLUMNS is lower than the output length of fish_prompt? How can my custom fish_prompt be useful if fish decides to use a static character instead of it all together?

For example, perhaps rather than just getting a > when fish thinks $COLUMNS is a low number, users might like their prompt to break into some kind of multi-line form where they still are presented all the information of their full prompt but in a different layout, making it more "responsive". Fish may calculate such a prompt as being too wide (since it ends up being a long, multi-line string) and render the single-character prompt instead.

[faho]

Except that from what I can tell has been established in this thread, fish will not use my fish_prompt if it determines that $COLUMNS is lower than the output length of fish_prompt?

To do that it first has to execute your prompt, so it can react.

Fish may calculate such a prompt as being too wide (since it ends up being a long, multi-line string) and render the single-character prompt instead.

Nope. It checks the longest line.

I actually have a fish_prompt that reacts to $COLUMNS. Unfortunately it doesn't _quite_ work - the prompt is executed before $COLUMNS is updated, so it'll only work after the second change - but the basic idea seems okay to me. It's also something that _should_ work.

So, @krader1961: There is something stopping someone from using a prompt that reacts to $COLUMNS, and that is #4381.

I think we still want a fallback of one character if it _really_ doesn't work, and I don't believe that needs to be configurable - this is one of those situations that you _really_ don't want to have, so choosing a prettier character is putting lipstick on a pig.

[faho]

I've closed this now by fixing #4381. Like I said, I think the proper way to handle this is for the user to make a prompt that reacts to $COLUMNS, instead of making the fallback prompt configurable.

[AntonioND]

My prompt is something like:

|HH:MM:SS user@host [current-path]                      git-describe|
|>>> cd ..                                                          |

I can do some magic with $COLUMNS and I can move the git-describe part if the rest is too long.

However, if the left part is simply too long (the path can easily make that part overflow) it is much saner to just wrap around than to make everything disappear. Losing all information about my current path just because it's too long is the exact opposite of what I want. If I'm lost in a folder tree, I want to know how many levels I have to go back.

All other shells wrap around by default. This is an unexpected behaviour that doesn't really improve the user experience, I believe (unlike the different shell language, etc).

The issue is that this doesn't really go well with the philosophy of the fish_prompt function. If the user wants to hide the prompt if it's too long, there is a way to do it by modifying the function. If I don't want to hide it and I want to wrap it, I can't.

[ridiculousfish]

Yeah I agree this should not have been closed. This should track either wrapping or truncating. It is not trivial to do but it ought to be possible.

[JoshCheek]

What about using the prompt's last nonwhitespace character for the single-character prompt? The likelihood is very high that it is what the user would choose.

[AntonioND]

Truncating may be a problem, there may be escape sequences that start a format but the sequence that ends it may be truncated (so the format may continue in the following line). If you just wrap around, even if it doesn't look great, at least the prompt doesn't behave in a different way than when it is not truncated.

[AntonioND]

@JoshCheek but why one character? I honestly don't know why removing all the information from the prompt is a good idea. I have a long prompt because I want that information. If I didn't care at all about it I would simply have a shorter prompt.

And again, if that's what you want, you can edit the function to do it.

[peey]

Here's what I've done to dynamically make my prompt smaller based on $COLUMNS. Might be useful with modifications to someone else. If the adapted version is too long then fish will fall back to > anyways, but this is good enough for me.

It wasn't exactly straightforward, so I don't think customizing is that easy and there should be better support in fish for handling this

I'm using a theme (cbjohnson) which uses a 2-line prompt, modify to suit your needs

functions --copy fish_prompt fish_original_prompt

function fish_medium_prompt
  # remove user@machine from prompt. For the theme cbjohnson it is the first four words of the first prompt line
  set first_line (fish_original_prompt | head -n 1)
  set rest (fish_original_prompt | sed -e '1d')

  echo "$first_line" | cut -d ' ' -f5-
  echo "$rest"
end

function fish_constrained_prompt 
  # force wrap prompt to $COLUMNS - 5 length
  set acceptable (echo $COLUMNS "- 5" | bc)
  fish_medium_prompt | fmt -w $acceptable 
end

function fish_prompt
  # color removal for correct length calculation from https://stackoverflow.com/a/18000433/1412255
  set original_length (fish_original_prompt | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | wc -L)
  set acceptable (echo $COLUMNS "- 5" | bc)

  set cmp (echo $original_length "<" $acceptable | bc)
  if [ $cmp = 1 ] 
    fish_original_prompt
  else 

    set modified_length (fish_medium_prompt | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | wc -L)

    set cmp (echo $modified_length "<" $acceptable | bc)
    if [ $cmp = 1 ] 
      fish_medium_prompt 
    else
      fish_constrained_prompt
    end
  end
end

I wasn't able to put the color-removing / prompt length calculation logic in a separate function. I think it's likely some issues with fish (I was stuck because of this, and even if I don't pipe stdin and rely on $argv, I'm still unable to get it to work).

Also fmt doesn't break a word if it's too long :/ so it won't work if your directory name / path is long, but the alternatives are worse (fold doesn't count unicode characters properly - so breaks git status, and par has problems with colored input I think)

In case anyone finds a way to improve the above, please do share.

[gkatsanos]

I opened this one https://github.com/oh-my-fish/oh-my-fish/issues/627 - I'm trying to do something similar I guess (control how it looks), first letter really isn't useful, I'd prefer only last directory

[faho]

@gkatsanos: Since fish 2.3.0, the prompt_pwd function that prompts typically use to get the pwd honors the $fish_prompt_pwd_dir_length variable. Set that to the number of characters per-directory or 0 for no shortening.

[znculee]

znculee/fish-theme-xtli
I forked a theme from oh-my-fish/theme-cbjohnson and revised it to be able to abbreviate prompt_pwd when the terminal become narrow, shown as following figure.

The key idea is to detect the number of columns of the top line of the prompt, and compare it with $COLUMNS to perform different prompt when the terminal become narrow of the prompt become too long.

[mixmastamyk]

Any news here? I've lost my prompt and wondering what to do.

Also > is a character to avoid in prompts because it it is dangerous on cut and paste. I use a unicode replacement.

I usually have the pwd shortening off, but would prefer it to this kind of shortening. How could I do that? Divide $COLUMNS by two and change the setting?

[znculee]

@mixmastamyk You may want to try this theme znculee/fish-theme-xtli.

[lionello]

Inspired by @wwwjfy, I ended up adding the following code to my ~/.config/fish/functions/fish_prompt.fish, right before the echo that prints the prompt:

    # shorten the prompt, but only when it's too long
    set -g fish_prompt_pwd_dir_length 0
    set -l longprompt $USER (prompt_hostname) (prompt_pwd) (__fish_vcs_prompt) $prompt_status
    if test (expr length "$longprompt") -gt $COLUMNS
        set -g fish_prompt_pwd_dir_length 1
    end

[DustVoice]

Inspired by @wwwjfy, I ended up adding the following code to my ~/.config/fish/functions/fish_prompt.fish, right before the echo that prints the prompt:

    # shorten the prompt, but only when it's too long
    set -g fish_prompt_pwd_dir_length 0
    set -l longprompt $USER (prompt_hostname) (prompt_pwd) (__fish_vcs_prompt) $prompt_status
    if test (expr length "$longprompt") -gt $COLUMNS
        set -g fish_prompt_pwd_dir_length 1
    end

Unfortunately this didn't satisfy my requirements. That's why I have written a script that does line wrapping of the prompt, as well as trimming of too long directory names for me.

If you're just here for the solution scroll to the bottom of this post.

Why this is a problem

Imagine for example if you have a directory

user@machine ~/very_long_directory_name_so_that_with_a_lower_columns_number_you_will_experience_the_described_behaviour/aab/dir
$

and a directory

user@machine ~/very_long_directory_name_so_that_with_a_lower_columns_number_you_will_experience_the_described_behaviour/aax/dir
$ 

fish would abbreviate both directories to

user@machine ~/v/a/dir
$ 

when using set fish_prompt_pwd_dir_length 1, where one would hope that it would abbreviate it after the first identifiying character instead. This leads to a huge amount of confusion, as the directory dir/ is present in both the directory aab and aax.

Imagine for example you have the following directories:

user@machine ~
$ ls
aaab/ aaba/ az/

fish doesn't abbreviate aaab to aaa, aaba to aab and az to az, or something like this, but instead abbreviates all of them to a sole a.

This is just really unfortunate, because why should I bother to have a directory display in my prompt in the first place, if I have to manually issue pwd evertime?!

How to solve this problem

Thats why I developed a script that automatically wraps directory strings that are too long (splitting the path at the / symbol) and trims the directory names that are too long.

In my case

user@machine ~/very_long_directory_name_so_that_with_a_lower_columns_number_you_will_experience_the_described_behaviour/aax/dir
$ 

would become (with $COLUMNS equal to 50 for example)

user@machine ~/
> very_long_directory_name_so_that_with_a_lower_colu[...]/
> aax/dir
$

Of course this solution isn't perfect, but it's sufficient for me at least.

The solution

To view the script, please consult my construct_column_aware_prompt.fish function for the function itself, as well as my fish_prompt.fish config on how to use said function.

[atheistd]

Wow! People have already been mad at this. How am I supposed to change this?! with $COLUMNS?

```
function fish_greeting
fortune
end

function fish_prompt

echo

set -l retc brblack
test $status = 0; and set retc bryellow

set -q __fish_git_prompt_showupstream
or set -g __fish_git_prompt_showupstream auto

function _nim_prompt_wrapper
    set retc $argv[1]
    set cust $argv[4]
    set field_name $argv[2]
    set field_value $argv[3]

    set_color normal
    set_color $retc
    echo
    echo -n ' ├─'
    echo -n '[ '

    set_color normal
    test -n $field_name
    and echo -n $field_name

    set_color -o brblack
    echo -n ' ▶ '

    set_color $retc
    set_color $cust
    echo -n $field_value

    set_color $retc
    echo -n ' ]'
end

set_color $retc
echo -n '─┬─'
echo -n '[ '

set_color -o red
echo -n (prompt_hostname)
echo -n ': '

if test "$USER" = root -o "$USER" = toor
    set_color -o brred
else
    set_color -o brwhite
end
echo -n $USER

set_color -o brblack
echo -n ' ▶ '

set_color -o brcyan
echo -n (pwd)

set_color $retc
echo -n ' ]'

# Virtual Environment
set -q VIRTUAL_ENV_DISABLE_PROMPT
or set -g VIRTUAL_ENV_DISABLE_PROMPT true
set -q VIRTUAL_ENV
and _nim_prompt_wrapper $retc '🐍 ' (basename "$VIRTUAL_ENV") cyan

# git
set prompt_git (fish_git_prompt | string trim -c ' ()')
test -n "$prompt_git"
and _nim_prompt_wrapper $retc (basename -s .git (git config --get remote.origin.url) 2> /dev/null) $prompt_git

# New line
echo

# Background jobs
set_color normal
for job in (jobs)
    set_color $retc
    echo -n ' │ '
    set_color brown
    echo $job
end
set_color normal
set_color $retc
echo -n ' ╰─> '
set_color normal

end```

[ridiculousfish]

I took a run at truncation. The approach is that, for each line of the prompt whose width exceeds $COLUMNS, we prepend ellipsis and then start removing characters from the left until it fits, while skipping escape sequences. I chose the left because it probably has the least interesting information (e.g. parent directories).

I personally prefer very minimalist prompts so probably this will need to be refined by someone who uses it. I think it's best to open new issues for any changes, as this one has been quite worked over.