display glitch with my zsh prompt

[RonnyPfannschmidt]

mosh 1.1 from debian testing in gnome-terminal currently doesn't display my zsh prompt if its in the last line (selection with curser will force it to be rendered tho)

the issue doesnt appear with zsh directly in gnome-terminal

as basic config for the prompt in shell i use:

    autoload -Uz promptinit
    promptinit 
    prompt clint

[keithw]

Could you please try this with the current master branch? We have fixed some color-related bugs that might have affected you.

[RonnyPfannschmidt]

just tried it, same issue

[voidmain]

Not sure if this is the same issue or not, but my zsh prompt is also pretty wonky on Mosh. I use some extended characters for drawing lines in my prompt and it appears that mosh can't draw them. I can open a separate bug and also send you my prompt configuration file.

[kmcallister]

@voidmain: How are you producing the extended line-drawing characters?

Mosh deliberately does not support the locking character set shift codes, such as \e(0. But the line-drawing characters exist in Unicode, so you can encode them statelessly as UTF-8. Also, programs like screen and luit will translate from locking codes to UTF-8 for you.

[voidmain]

Via the terminfo database. I didn't write the prompt but found it online. I mostly understand what it is doing, but some of the code I would need to research to fully understand.

Here's a snippet of my prompt that is setting an array from the terminfo acsc value:

typeset -A altchar set -A altchar ${(s..)terminfo[acsc]} PR_SET_CHARSET="%{$terminfo[enacs]%}" PR_SHIFT_IN="%{$terminfo[smacs]%}" PR_SHIFT_OUT="%{$terminfo[rmacs]%}" PR_HBAR=${altchar[q]:--} PR_ULCORNER=${altchar[l]:--} PR_LLCORNER=${altchar[m]:--} PR_LRCORNER=${altchar[j]:--} PR_URCORNER=${altchar[k]:--}

It is using the shift codes. I tested using mosh to connect to a remote server and then using screen and that appears to fix the issue. My guess is it is the shift codes that are messing things up.

[keithw]

Ah, yes, if this were an ncurses app it would automatically be using UTF-8 instead of the locking shifts. As it is you can certainly translate those into UTF-8 yourself if that works for you (it should work in any UTF-8 terminal, including ones that also support ISO 2022 locking shifts).

For altchar q (hbar), use ─ For altchar l (upper-left corner), use ┌ For altchar m (lower-left corner), use └ For altchar j (lower-right corner), use ┘ For altchar k (upper-right corner), use ┐

If you need more, just fire up screen (or "LANG=C luit"), type "tput smacs", and then type whatever letter you want and copy-and-paste it off the screen.

Cheers, Keith

[saurik]

It honestly seems like insisting "will not support locking shifts" is only a feature for people with terminals that lack a simple way to do a reset: these characters are actually used in the wild, and not supporting them and instead claiming that the people or applications that use them are wrong, seems unfortunately overly dogmatic.

I mean, if you want an option "do not support this part of the specification"--allowing the user to claim "I understand that not everything I render will render correctly, but at least I will never end up in hieroglyph mode"--that's one thing, but having that behavior by default is just asking for this bug report to persist and be reopened by people from time to time for the entire life of the project.

Further, this workaround isn't even reasonable (as, honestly, most of the workarounds proposed in these issues aren't): this user is not going to use mosh 24/7. Some of the terminals I come in contact with do not have Unicode fonts, or simply have horrible support for it; also, as you certainly well know, the settings for encodings and Unicode often get horribly broken while you are using random machines to SSH into random other machines and have interactions with screen.

Finally, some users, and I realize this may come as a shock ;P, aren't going to be using a Unicode encoding as their encoding-of-choice on the computer that they are connecting into. They may happily be able to handle Unicode being used at various points in the rendering of their terminal (and as so allowing mosh's "we convert everything to Unicode and you need a Unicode display terminal" to be reasonable), but their encodings and language tags are always going to be set to a local encoding (as they will need that for correctly interpreting the files that they are editing on their server). This is really common in Japan (and something I got an even better understanding of while being involved in the Ruby on Rails 1.9 Unicode push, as the core rails developers are mostly American while the core Ruby developers are mostly Japanese).

Instead of this, it seems like it would be much more in line with the way UTF-8 is handled and "fixed" to think through how to improve the terminal reset process. Right now, except in a few really broken and nearly useless terminals, I have no fear of hieroglyph mode: I just reset my local terminal state. As my terminal is now running remotely, it seems like I can simply have a remote reset, and now all terminals benefit from this feature: much more ideal than saying "if you want to run iftop while using this terminal you need to run it through this adapter" (which, I will point out, didn't even work for the user you told this to, which undermines this crusade that people should be using luit whenever they run into this problem).

http://news.ycombinator.com/item?id=3819759

Really, as the hieroglyph mode (already rare in daily use I will point out: I pretty much never end up there) pretty much always occurs in streaming mode (as opposed to in full-screen applications, where they are being used to draw part of the interface; it happening because a full-screen application either crashed or someone accidentally used cat or some other means to output a binary file to their console), one could then attempt to provide the following benefits:

1) when the terminal reset control sequence (maybe ctrl-^ R; whatever), is pressed, the terminal could not just clear and reset, but could also replay the contents of the screen with the lock disabled, allowing you to recover the contents that was destroyed.

2) the mechanism "ignore locking shifts" could be tri-state instead of on/off, with the third state being "ignore locking shifts only when in streaming mode, not when in full-screen mode", which will /not/ be good enough for some users (such as this person's prompt) but handles the common cases infinitely better than "no locking shifts at all".

3) one could imagine a more comprehensive auto-detection and repair facility (maybe another setting for "how to handle locking shifts") that realizes "wait, I'm in streaming mode, and I've just output an entire line of this garbage... that is almost certainly a mistake" and then automatically switches out of the locking mode.

[keithw]

Thanks for the detailed writeup.

Re: LANG=C luit, I still don't know why that didn't work for the user on ycombinator, but we have since learned that screen and tmux do work consistently for the same job. So that's what I would tell the Hacker News guy today. :-)

I do think the hieroglyph problem is annoying and this is a good opportunity to make a clean break. The mosh default does seem to work for >99% of use cases, because these characters almost solely come from ncurses which is happy to use UTF-8 if you ask it.[*] We have gotten some pretty happy feedback on this "feature." And I am pretty sympathetic to Markus Kuhn: "With UTF-8, it is not possible that your terminal remains switched to strange graphics-character mode after you accidentally dumped a binary file to it. This makes a terminal in UTF-8 mode much more robust than with ISO 2022 and it is therefore useful to have a way of locking a terminal into UTF-8 mode such that it cannot accidentally go back to the ISO 2022 world." (http://www.cl.cam.ac.uk/~mgk25/unicode.html#term)

But I am not dogmatic about UTF-8 and do like your suggestions, so let me think about it a bit more. Certainly if everybody wants an option to interpret ISO 2022 shifts, I guess we could probably do that...

[*] Apparently FreeBSD ships an ncurses that makes ugly ASCII characters when you ask it by default, instead of UTF-8... Another problem for this approach.

[kmcallister]

having that behavior by default is just asking for this bug report to persist and be reopened by people from time to time for the entire life of the project

That alone does not mean we should change this behavior. Every project has some bug reports like that.

saying "if you want to run iftop while using this terminal you need to run it through this adapter" (which, I will point out, didn't even work for the user you told this to, which undermines this crusade that people should be using luit whenever they run into this problem).

Please tone it down; this isn't a "crusade" on our part. We made a design decision and are interested to hear what people think about it. Obviously no choice will make everyone happy.

[saurik]

I apologize for using the word "crusade", but it is at least an honest expression ;P (...and frankly, one that was not at all meant to be harsh: I did not provide any kind of judgement about whether your crusade was for a noble and righteous purpose, only that it seems pragmatically inefficient and that the workaround is ineffective; please understand that I have gone through most of the public feedback regarding this project, from Slashdot/HN to the mailing and issue lists, so I'm not entirely ill-informed as to the kinds of things people are reporting and the workarounds that are offered ;P).

[RonnyPfannschmidt]

fwiw, i think its perfectly to choose not to support old glitches in favor of having a cleaner application design when hints are given on how to identify and fix those in the other apps

[grawity]

Just for the record, the PuTTY SSH client on Windows has never supported ISO 2022 when in UTF-8 mode.

[keithw]

Regarding the original bug, RonnyPfannschmidt, I still suspect that this is somehow color-related (because I don't have any other explanation, and mosh doesn't even know about any selection).

We have made the color code more conservative in a4221d17a by no longer posterizing 256color escapes to the nearest ANSI system color. Could you please try again with the current git master (on client AND server) and let us know whether the original bug has now been fixed? Sorry for the inconvenience.

[RonnyPfannschmidt]

still the same issue

[keithw]

Can you please send us a typescript of what the shell is generating? I can't reproduce this.

Please run script, then make sure to use the shell enough to have the problem happen, then exit the shell and post the resulting typescript file somewhere, and I'll take a look. Thanks.

Does the problem happen in any other terminals (e.g. xterm, urxvt) or just gnome-terminal?

[RonnyPfannschmidt]

just gnome-terminal it seems, pastebins/editors dont like typescript output it seems, can i email it to you?

[keithw]

Sure, feel free. keithw@mit.edu On Apr 18, 2012 11:57 AM, "RonnyPfannschmidt" < reply@reply.github.com> wrote:

just gnome-terminal it seems, pastebins/editors dont like typescript output it seems, can i email it to you?

---

Reply to this email directly or view it on GitHub: https://github.com/keithw/mosh/issues/115#issuecomment-5201973

[keithw]

Ronny, I still can't reproduce this using mosh-in-gnome-terminal.

Maybe you could post a screenshot?

To confirm, you are running mosh-client 1.1.94 and mosh-server 1.1.94 and it still happens?

[donaldsycamore]

I've seen what looks like the same issue with Mosh 1.1.3 (current debian). It's definitely gnome-terminal wierdness -- even just switching focus away from and back to gnome-terminal makes the text appear.

To reproduce I need to

• mosh to remote-machine (where my shell is bash)
• screen -r resume a screen session (in which I run irssi)
• Ctrl-A Ctrl-D to suspend the screen session
• ls

At this point, the bottom part of the screen isn't updated correctly (screenshot 1). If I select some text (screenshot 2), it appears. If I force a scroll-up by pressing enter, the terminal paints correctly (screenshot 3).

Screenshots are at http://cyg.net.nz/~donald/mosh/

[keithw]

Thanks for tracking this down. If you have a reproducible test case, can you try to capture it with "script" so it's just something you can "cat" to the terminal, and then report it to the VTE folks (the library behind gnome-terminal)?

I wonder if this has to do with GL compositing. I can't reproduce it here.

[keithw]

Closing as this does not seem to be a Mosh bug. The application (in this case mosh) does not know anything about the user's highlighting in the outer terminal.

[keithw]

Yes, I believe VTE and gnome-terminal fixed this bug in 2012 or 2013.

Both Mosh and PuTTY continue to enforce strict ISO 10646 UTF-8 and do not allow ISO 2022 charset switches.

[keithw]

What ISO 2022-generating programs are you using in 2017? :-)