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

Terminal issue: lines that wrap in (or near) colour changing statements do not wrap to the next line #18

Closed
erikhuizinga opened this issue Dec 2, 2016 · 12 comments

Comments

@erikhuizinga
Copy link
Contributor

erikhuizinga commented Dec 2, 2016

I have a problem when the prompt string is a few characters longer than the window width and a branch name is displayed.

The screenshot below illustrates the issue.
schermafbeelding 2016-12-02 om 14 09 38
What you can see is the branch name is displayed, then the three stacked lines, but then the closing square bracket ] is shown in blue (instead of yellow) near the beginning of the first line. Also, the input cursor is shown close after the closing square bracket and dollar sign: ] $ |. The yellow pipe | is my cursor, yellow is the intended colour by the way. Also, the working directory is intended that way, it's there so the dir is quite long. Instead, I could have chosen a very long branch name for similar results.

In my ~/.bash_profile I have set the following.

export PROMPT_COMMAND='__posh_git_ps1 "$prefix" "$suffix";'$PROMPT_COMMAND

where $prefix is my username@hostname workingdir and $suffix is $, both with some colour specification, but nothing more.

When the Terminal window is a little smaller, the problem does not occur; see screenshot below for a terminal window of 77 characters wide. The one above is 80 characters wide. The problem occurs when the windows is 78, 79 or 80 characters wide. Narrower or wider windows behave correctly.
schermafbeelding 2016-12-02 om 14 21 23
For very narrow Terminal windows (or very long working directories) the problems become worse, especially when the prompt string should wrap around more than 2 lines. Try resizing the Terminal window in a similar situation as my current screenshots show, with quite a long working directory.

@lyze
Copy link
Owner

lyze commented Dec 3, 2016

I am unable to reproduce this. My strong suspicion is that you have not wrapped your color codes in \[ and \] for bash (or %{ and %} for zsh). This Stackoverflow post has a well-written explanation of this problem. Could you please paste the exact mumbo jumbo used to set PROMPT_COMMAND?

@erikhuizinga
Copy link
Contributor Author

erikhuizinga commented Dec 4, 2016

Here's the exact code.

export PROMPT_COMMAND='__posh_git_ps1 "\[\e[00;37m\]\u@💻  \[\e[00;31m\]\w" "\[\e[00;37m\] \$ \[\e[00m\]";'$PROMPT_COMMAND

I know bash does not know the number of printable and unprintable characters, so those should be grouped in \[ and \]. I guess the grouping I currently have is correct, but if you spot any error I'd like to know!

I figured it could be caused by some quirk concerning the laptop emoji 💻 I use. Because it prints in a different font (because my monospaced console font, Source Code Pro, does not support it) it is wider than the terminal font and requires two spaces after the character. However, I tried replacing it with \h and the results did not change.
schermafbeelding 2016-12-04 om 11 01 06
I conclude that a line breaking in the middle of or near the posh git string may cause the incorrect wrapping problem.

@lyze
Copy link
Owner

lyze commented Dec 7, 2016

After a little bit of poking around, it just seems that the particular emoji doesn't play nicely at all with the terminal. I opened up a boring terminal prompt, pasted it in. It caused havoc to my prompt if I tried to edit the line and if it was a long line. This feels like a limitation in bash or the terminal emulator. Can check that taking out the emoji eliminates the problem?

@erikhuizinga
Copy link
Contributor Author

@lyze As I said in my previous comment: I can reproduce the problem without the emoji, so the issue isn't caused by it.

@lyze
Copy link
Owner

lyze commented Dec 10, 2016

I can't reproduce the problem when using \h on my own computer. (Caveat: It wasn't on a Mac, and I don't have a Mac handy to test.)

The actual expansion of PS1 with \h:

\[\e[00;37m\]\u@\h \[\e[00;31m\]\w\[\e[1;33m\] [\[\e[1;36m\]master ≡\[\e[1;33m\]]\[\e[m\]\[\e[00;37m\] $ \[\e[00m\]

I can't see anything wrong with it.

I'm really scratching my head here. Some theories that I would need you to help investigate:

  • Is there anything else in $PROMPT_COMMAND that might mess with $PS1?
  • Have you tried setting shopt -s checkwinsize?
  • Try messing with the terminal emulation settings? I think it's "Preferences > Advanced > Emulation".
  • Try using tput instead of ANSI colors.

@erikhuizinga
Copy link
Contributor Author

Great ideas! Here are my results. (spoiler: no luck...)

  • Yes, my $PROMPT_COMMAND contains (before prepending my posh Git string): update_terminal_cwd. Removing it does not change the issue.
  • It was already set and explicitly setting it does not change the issue.
  • How do I do this? Is it under Prefs > Advanced > Terminfo (where it says xterm-256color by default)? I tried about 5 different values there and it does not change the issue.
  • Currently, my $PROMPT_COMMAND implementation is:
red=$(tput setaf 1)
gray=$(tput setaf 8)
reset=$(tput sgr0)
export PROMPT_COMMAND='__posh_git_ps1 "\[$gray\]\u@\h \[$red\]\w" "\[$gray\] \$ \[$reset\]";'$PROMPT_COMMAND

The issue persist, unfortunately.

Even when using export PROMPT_COMMAND='__posh_git_ps1 "\u@\h \w" " \$ ";'$PROMPT_COMMAND or export PROMPT_COMMAND='__posh_git_ps1 "foo bar" " baz qux ";'$PROMPT_COMMAND does not change the issue.

@lyze
Copy link
Owner

lyze commented Dec 12, 2016

If you clear PROMPT_COMMAND and only set PS1, does the problem still occur?

PROMPT_COMMAND=
PS1=\[\e[00;37m\]\u@\h \[\e[00;31m\]\w\[\e[1;33m\] [\[\e[1;36m\]master ≡\[\e[1;33m\]]\[\e[m\]\[\e[00;37m\] $ \[\e[00m\]

@erikhuizinga
Copy link
Contributor Author

Using

PROMPT_COMMAND=
PS1='\[\e[00;37m\]\u@\h \[\e[00;31m\]\w\[\e[1;33m\] [\[\e[1;36m\]master ≡\[\e[1;33m\]]\[\e[m\]\[\e[00;37m\] $ \[\e[00m\]'

(i.e. what you said, but with 'quotes')
the results are the same. Something is wrong in the way Terminal wraps a line with grouping of non-printable characters. I think the line break it should insert ends up erroneously within the unprintable group, so it gets ignored somehow.

I guess this rules out posh-git-sh as the culprit, don't you agree? Where do I go next with this issue? The current behaviour is ok if the Terminal window does not have the problematic width (which is one of two or three widths depending on the length of $PS1 when it prints).

I guess I'll have to resort to a Terminal alternative.

@lyze
Copy link
Owner

lyze commented Dec 13, 2016

I'm out of ideas at the moment. By now, I, too, am fairly confident that posh-git-sh isn't the culprit here.

A long shot. Do you think you need to update bash or Terminal itself?

Also, I think you may want to consider filing an Apple bug report.

@erikhuizinga
Copy link
Contributor Author

I work on Terminal v2.7.1 (387), which is the latest stable release according to Wikipedia at the moment of writing. Also, I'm running Bash v4.4.5(1)-release (echo $BASH_VERSION), again, the latest stable version according to Wikipedia.

I'll contact Apple about the issue.

@erikhuizinga
Copy link
Contributor Author

Thanks for taking the time to look into this! 👍 I hope I'll find a solution for this (and if so, I'll report back here).

@erikhuizinga erikhuizinga changed the title Prompt with branch name wraps on the same line Terminal issue: lines that wrap in (or near) colour changing statements do not wrap to the next line Dec 14, 2016
@erikhuizinga
Copy link
Contributor Author

I've opened a discussion thread here.

erikhuizinga added a commit to erikhuizinga/posh-git-sh that referenced this issue Dec 16, 2016
lyze pushed a commit that referenced this issue Dec 21, 2016
@lyze lyze closed this as completed Dec 21, 2016
lyze pushed a commit that referenced this issue Dec 21, 2016
lyze pushed a commit that referenced this issue Dec 21, 2016
lyze pushed a commit that referenced this issue Dec 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants