Hyper: PS1="〉" terminal prompt glitches

[folletto]

• [x] I am on the latest Hyper.app version

• [x] I have searched the issues of this repo and believe that this is not a duplicate

• macOS 10.12.1

• Hyper.app 1.0.0.1303
• default .hyper.js
• Dev Console error: __WEBPACK_IMPORTED_MODULE_0_hterm_umdjs__.hterm.TextAttributes.splitWidecharString
  (full stack screenshot)
• vanilla Hyper

Issue

When I updated to Hyper 1.0 (from a previous 0.x I can't recall, which worked) the prompt looked off. What's worse, some operations didn't work properly either:

1. the color of the prompt leaked.
2. preferences didn't open, just duplicated the same content of the original tab and crashed them all if I attempted to close one (screenshot).
3. CMD+W and CMD+T seem not working / work randomly.

I hunted the issue down, and removing piece by piece every element in my custom PS1 prompt, I identified it breaks when I add this character: 〉.

Specifically, the smallest bash prompt that breaks is:

PS1="〉"

Might be useful:

$ echo -n 〉| hexdump
0000000 e2 8c aa                                       
0000003

The same happens with:

PS1="〉"

$ echo -n 〉| hexdump
0000000 e3 80 89                                       
0000003

And other random characters:

PS1="、"
PS1="ㄐ"
PS1="㈑"

If I change the prompt to anything else, it works. Similarly, if I keep my prompt but I just remove that character, it works again.

Also: I can't copy paste the above PS1 commands into Hyper either: the paste itself "breaks" at the character.

[dotcypress]

Hopefully fixed by https://github.com/zeit/hyper/pull/1111

[dotcypress]

@folletto could you try to build Hyper from this branch and try again?

[folletto]

I confirm that branch fixes the issue, but not completely.

The cursor becomes offset by roughly a single space:

Typing ll in Hyper (that unicode-perfomance-fix branch):

Typing ll in Hyper 1.0 (with the bug mentioned here):

Typing ll in Hyper 1.0 (with a PS1="$ " prompt):

Typing ll in Terminal:

[dotcypress]

@folletto but this space provided by PS1="〉", right?

UPD: NVM

[adityavm]

not sure if this is related, but my prompt is:

%{$fg_bold[blue]%}〉%{$fg_no_bold[white]%}%p%{%F{247}%}%c ·%{$reset_color%}

(same '〉' character in the prompt) and my hyper is a blank window

[folletto]

With Hyper 1.0.1 (that had https://github.com/zeit/hyper/pull/1111 merged) now the prompt has the visual glitch of the space, but at least doesn't break functionality (at least to the extent I tested it).

Current 1.0.1 (notice the misplaced space):

[cirqueit]

My off-by-one behavoir (seen above in @folletto 's post) was caused when using NOCOLOR in my prompt

NOCOLOR="$(tput sgr0)"

I modified NOCOLOR to instead paint text white

NOCOLOR="$tput setaf 7)"

Now I'm good. Hope it helps!

[storvik]

Having the same problem as @folletto with 1.0.1 when spawning a tmux session. Invoking the tmux prompt (C-b :) fixes all preceding lines (shifting them one character to the right again), but when entering a new command it's back to being off to the left by one. Using zsh and powerlevel9k.

All space between left and right prompt is also removed. Everything works as expected when not in a tmux session.

Icon bug is likely related to #1327

[jrop]

I don't know if this pertains to this issue or not, but I am getting an out-of-place cursor when using tmux after updating to the latest Hyper (1.1.0.1408):

(sorry for the slow replay...I don't know why it plays back so slowly; EDIT: fixed to normal replay speed)

[jrop]

1332 seems to be related to this. But there seems to be something more fundamentally wrong:

My PS1 looks like this: "%B%F{green}~%f %F{cyan}λ%f%b "

Note that the %b (</bold>) occurs before the trailing space.

When running outside of TMUX, the generated HTML is:

<x-row><span style="color: rgb(0, 186, 19); font-weight: bold;">~</span><span style="font-weight: bold;"> </span><span class=" unicode-node" style="color: rgb(0, 181, 189); font-weight: bold;">λ</span> <span style="color: rgb(239, 41, 41); font-weight: bold;">asdf</span></x-row>

However when running inside TMUX, the generated HTML is instead:

<x-row><span style="color: rgb(152, 195, 121); font-weight: bold;">~</span><span style="font-weight: bold;"> </span><span class=" unicode-node" style="color: rgb(86, 182, 194); font-weight: bold;">λ</span></x-row>

...until I type a character, it becomes:

<x-row><span style="color: rgb(152, 195, 121); font-weight: bold;">~</span><span style="font-weight: bold;"> </span><span class=" unicode-node" style="color: rgb(86, 182, 194); font-weight: bold;">λ </span><span style="color: rgb(224, 108, 117); font-weight: bold;">asdf</span>         </x-row>

Note that it puts the space within the bold span with the λ character, which is wrong. According to my PS1 string, the space occurs after the bold ends.

Another note, even if the string was in the bold markup, this problem would be fixed if #1332 were fixed.

[adworacz]

Oh thank god, I'm not the only one. I'm using the latest (1.2.1.1527) and experiencing this issue when I use TMUX. It's really quite infuriating and works just fine in iTerm.

[adworacz]

This is still occurring with 1.3.1. In fact, tmux use in hyper seems quite broken as even my status bar at the bottom is rending oddly, like the window size isn't being communicated to TMUX properly.

[jrop]

@adworacz I've sadly had to stop using hyper altogether. I am keeping an eye on this issue, however, hoping that the devs fix this! From what I understand, once they switch to xterm.js, this might fix itself (#1275).

[adworacz]

@jrop I have to agree. I'm continuing to use iTerm for the time being, as I need tmux support in order to work properly.

Thank you for pointing out the potential migration to xterm.js, I'll be sure to track it.

[hugomd]

I also have the same issue

[jrop]

@adworacz My specific issue is gone in version 1.3.3.

[folletto]

Thanks for the update, I checked: the issue is still present in v1.3.3.

[adworacz]

I can't replicate my issue on 1.3.3.

At least, not yet. Will keep experimenting, but thank you for fixing the core issue.

[MelkorNemesis]

I still keep getting this error on 1.3.3.

[AnonymousArthur]

I'm getting the same error in 2.0.0 ...

[albinekb]

Please open a new issue for 2.0 @ultraN