Hyper: Text Wrapping Problem

[xscheiner]

On the screen grab below you can see part of a command:

Here is what happens when I type the next character:

I typed an s to complete the word 'works' and then like which started to appear over the other text which was no longer visible.

[michalkopanski]

Noticing the same thing. Here's a .gif of the interaction:

[michalkopanski]

Also a related bug: When you submit a command that was wrapped, it will break the "Press up to access previous command" feature.

Pressing UP then DOWN keys after a wrapped command:

Pressing UP and DOWN keys after a non-wrapped command:

[mauro-oto]

Also see: https://github.com/zeit/hyperterm/issues/64

[albinekb]

Can't reproduce this, what version are you running?

[mauro-oto]

@albinekb I believe this was fixed since the addition of the LANG environment variable. Using the "C" default instead of the "en_US" or "en_US.UTF-8" strings reproduces the broken wrapping behavior.

[albinekb]

Nice, so we can close this one and #64 ?

[mauro-oto]

@albinekb I'd say so, @rauchg?

[trevordmiller]

This seems to still be a problem; here is a duplicate issue with more information: https://github.com/zeit/hyperterm/issues/64

[markpanado]

I'm still also experiencing this after changing PS1 in my ~/.bashrc:

I noticed it will only start wrapping after the second line:

[cfjedimaster]

I'm seeing this as well, but on Windows 10.

[mwheeler]

I'm also seeing this on Windows 10... still almost a month later.

[neolectron]

+1

[unleashit]

Also have had this problem off and on with Windows. Went to troubleshoot by doing a clean install of hyper (including removing all Hyper settings in AppData) but now it's working correctly and I can't reproduce. May have something to do with what I had in my dotfiles but at the moment I'm not sure.

[unleashit]

Spoke to soon, the problem came back. I'll also jump on the screencast bandwagon since my issue is a bit of a variation from the the above. It's a bit different whether I'm in zsh or bash, and notice what happens when I backspace:

Everything was fine until I added a couple of plugins to my .hyper.js without installing them first (I'm new to Hyper and didn't know that was a key step (duh), After seeing the notification that hyper wasn't happy, I installed the plugins. Didn't fix the wrapping issue, neither did reverting my .hyper.js to the original. I'm not saying adding the plugins is what triggered it, but that's exactly all I did before the problem began.

Also notice that the title is truncated in the title bar (separate issue).

Unfortunately, this is all the time I can invest in Hyper. Hope you guys can get it sorted.

[OmgImAlexis]

Same thing here, it mainly happens over ssh for me. I'm using ZSH locally but it also happens even if I disable zsh and use bash/sh.

I'm OSX if that matters.

[cfjedimaster]

Any update on this? The bug is still closed, but obviously folks on multiple platforms are still hitting it.

[OmgImAlexis]

@CodeTheory could this please be reopened?

[timothyis]

Thanks for the mention @OmgImAlexis.

We're currently in the process of switching out hterm for xterm.js and I think hterm is the cause of this issue. Will ask if that switch out fixes this when there's more progress.

cc @chabou @rauchg @ppot

_Also_, for the record, I can't reproduce the issue.

[OmgImAlexis]

The easiest way I've found to reproduce it is ssh to a server and just cat a binary file. It should throw the RAM usage to 1GB+ and essentially freeze to the point of a crash.

[unleashit]

If it helps, I've recently found that I have the same issues intermittently with stock WIndows 10 bash.exe when called inside a wrapper or emulator. Those would be PhpStrorm with C:\Windows\System32bash.exe as the terminal, Conemu with the same. With the stock WSL bash terminal or git bash, there are never any issues.

Interestingly, the problem doesn't happen in Visual Studio Code when Bash is linked to via Sysnative: "C:\WINDOWS\Sysnative\bash.exe"

As far as I know Sysnative is some sort of routing alias that determines whether to launch a 32 or 64 bit version of the exe. I tried using that path in both Hyper and PhpStorm but both editors just crash.

So now I'm inclined to think Hyper isn't the root of (at least my) problems. Maybe not Windows Bash either, if this is the same (and it looks the same) as the issues that Mac users are having. For me it's very strange because intermittently it will work fine for awhile. I could very well be doing something something doesn't like in my .bashrc or .bash_profile. I'm not a bash expert but as soon as I have enough time (not much ATM), I'll experiment by resetting everything to the default. Drives me nuts, because I was just starting to get into using Bash on Windows...

[OmgImAlexis]

@unleashit I get the same issue with sh and bash so I doubt it's bash that's the underlying issue at least not for all of us.

[unleashit]

And zsh. But what I'm saying is I'm getting the same issues outside of Hyper.

Well boys and girls, I found a hacked solution that at least for now is giving me more room to work. Maybe it will give someone smarter then me a clue. The columns of my embedded terminals default to 80, and that's exactly the point that the evil line wrapping begins. Someone on Stackoverflow suggested using the command screen (which is basically like Tmux right?). On my system the program itself fails/aborts right away for some reason (missing dep or Windows related?), but I do a quick ctrl-C and presto, line wrapping issue goes away. When I run echo $COLUMNS it jumps to the size the window is open to. Both in bash and zsh.

I'll do this until we get to the heart of the matter.

[DaveyJake]

UPDATE: July 28, 2017
Opened up Hyper for the first time since I initially posted the comment below. The long lines issue is once again an issue.

---

Not sure if this will help others but it worked for me. Inside of .hyper.js I removed the following plugins: hyperterm-safepaste, hyperlinks, hypertheme, hyperterm-cursor.

I'm now only running hyperterm-cobalt2-theme and hyper-mac-controls. My long lines wrapping problems are no longer problems at all. This was all on my work machine which runs Windows 10.

[dpodsiadlo]

I noticed something related to @unleashit mentioned:

1. When I open Hyper and run tput cols it says 80
2. When I open vi and close it the tput cols returns 197 and the problem with line wrapping goes away.

I'm using Hyper with Bash on Windows 10, also installed oh-my-zsh.

[OmgImAlexis]

Tried what @dpodsiadlo stated on OSX and tput cols returns the same amount of columns before and after vi, vim and nano.

[huiguang-liang]

@dpodsiadlo @OmgImAlexis can confirm. tput cols returns 80 before vi and a more reasonable number after vi.

[unleashit]

I'm not sure if there are multiple issues going on, for me I've narrowed it down to Windows Bash not behaving well in an emulator. Bash.exe has the same erratic behavior for me in multiple emulators, not just Hyper. Unfortunately, I haven't found a really workable solution and have switched back to using Git Bash until MS get it together (or I switch to Ubuntu).

[cfjedimaster]

@unleashit have you had a chance to try it with the "Store" release of Unbuntu? Ie the out of beta version. (You need to be on an Insiders build to see it.) I'm running this myself, with Hyper, but as the bug didn't occur every day, I've yet to see it. (And I've only been running this version for 2 days.)

[cfjedimaster]

Ok I'm dumb - there was a simple test above. So I opened a new tab in Hyper (again, using "Release" Ubuntu), and ran tput cols both before and after. For me, it returned the same value. So perhaps it is fixed?

[OmgImAlexis]

@cfjedimaster it's not fixed I get the same number both before and after yet still have the issue.

[cfjedimaster]

Ah ok. While I hit this issue a few times a week, I was never able to consistently reproduce it. Do you know a way? If so, I'll test.

[unleashit]

@cfjedimaster I've thought about it, but after reading that I would have to agree to give my keyboard strokes, expanded telemetry, etc. to MS, it was a non-starter. Not that they're not taking it anyway, but I digress...

[cfjedimaster]

@unleashit Well, you can still upgrade in the Fall I suppose. As an FYI, I've contacted a person @ MS about this issue in case folks are right, that it is an issue with bash.exe/ubuntu.exe and not Hyper at all.

[unleashit]

Thanks, that's really the right thing to do. There are some Mac users with similar issues, but mine (and others) seem to be Bash for WSL related. I don't have another Windows machine ATM to compare to totally rule out something with my environment, but since I'm not the only one it seems like it could be a problem (at least on certain software/hardware).

[nexusondesign1]

I'm getting also issues with using hyper with Bash on Ubuntu on Windows when I use something like git commands or any other long command or text i type in the hyper terminal the terminal emulator text wrapping looks really messed up sometimes the text overlaps and sometimes it jumps on the top of another text. Really liking the hyper terminal emulator a lot but I really hope this issues can get fixed soon. Because it makes working with the application very hard with that issue :)

[TheSETJ]

I use zsh as bash in Linux subsystem of Windows 10 through Hyper. I have the same issue. I just want to know if there is or there will be any fix?

[ines]

I came across this thread looking for a solution – here's what fixed it for me, so maybe this is useful to others as well until the underlying problem is resolved:

I'm using zsh with a custom theme and prompt. The weird line wrapping would usually happen with an offset of one character – i.e. Hyper would incorrectly wrap one character too early, causing the weird, glitchy overwriting and occasionally one "hanging" character above. First, I verified that manually overwriting the prompt via export PS1="\$ " (as described in #64) made the problem go away. Disabling the zsh prompt fixed it, too – but this was pretty unsatisfying.

Turns out the problem was that my custom prompt included the non-ASCII character ▲. Replacing it with a $ did the trick 🎉 (I suppose this also works with any other ASCII character.) The colour didn't make a difference btw – at least not via the zsh theme. So for now, I'm using a coloured $ instead of the ▲.

[TheSETJ]

@ines, unfortunately, does not work for me.

[Mohamed3on]

Same problem with oh-my-zsh on Windows. Can't reproduce with the original bash on Windows terminal, but can confirm changing the prompt to $ fixes it temporarily as @ines said. Really hope this gets fixed.

[nexusondesign1]

I think it got now fixed by the Developer of Hyper, I downloaded today the new installer from his website https://hyper.is/ and the problem went away. I'm using Hyper with Bash on Ubuntu on Windows and it works now I don't get any text wrapping issues anymore.

I recommend all install the latest version today and let me know if that fixes the text wrapping issue also on your end :)

Thanks Zeit for the update!

[TheSETJ]

I confirm what @TheNexusDesigns said. The issue is not there anymore.

[dpodsiadlo]

@TheNexusDesigns and @TheSETJ, I confirm that as well.

[dougmaitelli]

@TheNexusDesigns Issue solved for me also

[albinekb]

❤️ Wonderful, I'll close this here! Re-open if you still have this problem.

[gregorygenova]

Hi, It's still buggy for me with hyperzsh plugin on macOS sierra / Hyper v.1.4.2.

[albinekb]

Ok, so still not fixed... Let's not put too much time into this as it will be fixed with the xterm switch!

@gregorygenova can you try with a fresh .hyper.js? (move your and restart hyper to get the default config)

[gregorygenova]

Hello, I have the same issue with a fresh .hyper.js.
I installed oh-my-zsh (https://github.com/robbyrussell/oh-my-zsh).
It seems Hyper is incompatible with oh-my-zsh because on iTerm2 I don't have this issue.
I reinstalled oh-my-zsh with a clean config and restart Hyper, but there is the same issue.
As you can see on my screenshot, often it just the two first characters of the command that stay fixed on TAB press. Also I have some trouble on the long command lines when it wraps.

Sorry for my english, I'am french :)

[JacobDB]

For the record, it seems to be fixed for me as well, on Windows 10 Pro Version 1703 (OS Build 15063.40).

[albinekb]

Ok so we can narrow it down to it being a problem with zsh?

[christianalares]

I'm using the latest Hyper.app with Pure with the theme Hyper Snazzy. I found that the problem disappeared when i took out these lines from my .zshrc file:

# Load Pure

autoload -U promptinit; promptinit
prompt pure
setopt autocd

Could this be to any help?

[OmgImAlexis]

@christianalares I don't have any of those commands in my zsh or bash setup and still have the issue so it's possibly not related.

@albinekb I get the issue with zsh, bash and sh.

[christianalares]

@OmgImAlexis Maybe you have something that Pure has? Are you exporting colors somewhere something like: \e[2J\e[0;0H? edit: This doesn't exporting colors, it's supposed to _clear screen and move cursor to (0, 0)_ whatever that means...
Before when I ran bash and Terminal.app I had a function like this in my .bash_profile that gave me similiar problems:

parse_git_branch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

I don't know why but maybe that gives someone else any clues...

[OmgImAlexis]

Here's my whole .zshrc file minus commented out blocks. .bashrc is empty and I still get the issue without zsh running.

➜  ~ cat ~/.zshrc
# Path to your oh-my-zsh installation.
export ZSH=/Users/xo/.oh-my-zsh

# Set name of the theme to load. Optionally, if you set this to "random"
# it'll load a random theme each time that oh-my-zsh is loaded.
# See https://github.com/robbyrussell/oh-my-zsh/wiki/Themes
ZSH_THEME="robbyrussell"

# Uncomment the following line to change how often to auto-update (in days).
export UPDATE_ZSH_DAYS=7

plugins=(git docker yarn)

# Make nvm load only when needed
export NVM_LAZY_LOAD=true
plugins+=(zsh-nvm)

source ~/.git-flow-completion.zsh

source $ZSH/oh-my-zsh.sh

# User configuration

alias changed="git diff HEAD --staged -- . ':!yarn.lock'"
alias dl="docker logs -f --tail=100 $1"
alias see="tree -a -I .git"
alias socks="~/.socks"
alias size="~/.size"
alias agendash="~/code/agendash/bin/agendash-standalone.js --db=mongodb://localhost/twistly --port=3001"
alias reload="source ~/.zshrc && clear"
alias spa="~/code/.not-quite-dotfiles/bin/spa-server/index.js"
alias c="clear"
alias fix="yarn xo --fix"

# Allow fuck to fix commands
eval "$(thefuck --alias)"

# added by travis gem
[ -f /Users/xo/.travis/travis.sh ] && source /Users/xo/.travis/travis.sh

# Fix yarn globals
export PATH="$PATH:`yarn global bin`:$HOME/.config/yarn/global/node_modules/.bin"

# Setup ruby
eval "$(rbenv init -)"

# Setup GoLang
# http://www.golangbootcamp.com/book/get_setup
export GOPATH=$HOME/code/go
PATH=$PATH:$GOPATH/bin

[christianalares]

So I see you’re using oh-my-zsh. What if you comment out oh-my-zsh specific stuff from you’re .zshrc file?

[OmgImAlexis]

Like I said same issue even if I use a new clean bash or sh prompt without zsh and/or oh-my-zsh.

[lubokkanev]

@ines Turns out that was my problem all along - I had some missing escapes in my PS1 prompt. Been living with that for far too long, thanks a lot!

[agilgur5]

Went on the canary channel and still experienced this problem (even though that should be using xterm.js now). I also switched to iTerm2 and still experienced this error there, so in my scenario at least, it was neither a Hyper nor hterm issue.

Turns out the error was with non-printable characters in my $PS1 and I resolved it by following the instructions here: https://unix.stackexchange.com/questions/28827/why-is-my-bash-prompt-getting-bugged-when-i-browse-the-history

Here's the relevant portion of my .bashrc -- color variables are the only things that change:
before:

reset='\e[0m'
cyanbold='\e[1;36m'
export PS1="\n\w [\T] \n $cyanbold λ >$reset "

after:

reset='\[\e[0m\]'
cyanbold='\[\e[1;36m\]'
export PS1="\n\w [\T] \n $cyanbold λ >$reset "

or to show as a one-line example for clarity:
before: \e[0m
after: \[\e[0m\]

Putting escaped brackets, \[ and \], around non-printable characters, i.e. \[...non-printable characters here...\] solved my issue! Hope it helps someone else as that was quite annoying to deal with for a few weeks! 😌

[zsoltuveges]

I had the same problem now... I opened the .zshrc file, and there are these lines :

# You may need to manually set your language environment
# export LANG=en_US.UTF-8

Just delete the # before the export line... It works for me!

[chabou]

@zsoltuveges OMG! What you find is awesome... Seems unrelated but it works!
I can reproduce with a LANG set to fr.UTF-8 (I really don't know why I have this value) but setting it to fr_FR.UTF-8 fixes this issue 😮

[ZeFifi]

You're right, that's why I did and it works (and I can use special characters such as é à etc, without having <ffffffff> in the terminal instead)! Thanks!

[chabou]

Should be fixed with our v2

[jcklpe]

Maybe this issue is related to https://github.com/zeit/hyper/issues/2930 that I'm having?

[PgAuffret]

Hyper: 2.0.0 (stable)
OS: Windows 10 Pro 1809 (17763.55)
WSL: Ubuntu on Windows 18.04 LTS

Hello,
Please find bellow a snip of a glitch:

As the snip shows, when the more command is called, some text lines are strangely wrapped.
This behavior may easily be reproduced with lsb_release -a command

[cihankoseoglu]

Issue is back, I'm using 2.1.0

[willycamargo]

Similar issue here, using 2.1.0 with zsh and oh-my-zsh

[jcklpe]

I think it might be something about oh my zh. I was having problems and now I'm not. And at some point I got rid of oh my zsh because I found it largely over complicated my zsh plugin maintenence but I think maybe also I found it caused this issue. Not sure though. It's been awhile since I removed it.

[bkjoel]

I had the same problem now... I opened the .zshrc file, and there are these lines :

# You may need to manually set your language environment
# export LANG=en_US.UTF-8

Just delete the # before the export line... It works for me!

I've had the same problem - using Hyper 2.1.0, zsh 5.3, spaceship prompt 3.9.0.
When typing and the line would reach the end of the window it wouldn't wrap properly to the second line but will begin overwriting the same line (prompt's line).

Added the export command above to my .zshrc and it did wonders!
thanks.

[cihankoseoglu]

Can confirm that @zsoltuveges solution works for me, on Mac OS Mojave and Hyper 2.1.2

[pocketbird]

Initially solved this problem by adding the LANG env var but, just noticed that when I include an emoji in my bash PS1 it wraps text again.

In .bash_profile:
PS1="\[\033[33;1m\]\w\[\033[m\]\[\e[0m\]\[\033[36m\]\$(__git_ps1)\[\033[m\] 🎉 "

_The $(__git_ps1) is for displaying git branches_

[Dibasic]

I encountered this issue in 3.0.2 with LANG=en_US.UTF-8. The issue occurred any time I included colors e\[...m in PS1. The cursorBlink setting also did not work. Removing all colors from PS1 solved both issues.

Specifically, this line in .bashrc resulted in the issue: PS1="[\u@\h:\e[95m\`parse_dirs\`\e[0m]` \e[93m$\e[0m "

and replacing it with this line fixed both issues: PS1="[\u@\h:\`parse_dirs\`] $ "

(parse_dirs is a dirs | perl -pe 's/.../.../')

[mcshaman]

I am also having this issue. Any time I have a emoji in my PS1 I get the line wrapping issue. I am running. Bit sad... I wanted to bring a little happiness to my CLI. Running version 3.0.2 bash on Ubuntu.

[IdanCo]

@bkjoel solution worked for me.

For some reason the line wrap issue manifested for me only on IntelliJ WebStrom terminal.

[Project-42]

I have same issue in chromeos/crostini and the current workaround was to disable the clock emoji from the bash-it prompt as @mcshaman already mentioned (THANK YOU!!)