xterm emulation incompatibilities #155

Closed
peterjeremy opened this Issue Apr 12, 2012 · 10 comments

Comments

Projects
None yet
3 participants
Contributor

peterjeremy commented Apr 12, 2012

I have been working through the vttests provided with xterm-278 and found the following areas where the current GIT version of mosh is missing functionality (comments in parentheses refer to the actual test scripts):

  • No support for highlighted colours (colours 8-15 in 16colors.sh)
  • Changes only affecting attributes are not transferred to the client (acolors.sh)
  • Reading terminal colours doesn't work (dynamic.pl)
  • Dynamically changing colours doesn't work (dynamic.sh, dynamic2.sh)
  • Dynamically changing fonts doesn't work (fonts.sh)
  • Base64 cut/paste doesn't work (paste64.pl)
  • Reading and dynamically changing terminal size doesn't work (resize.pl, resize.sh)
  • Reading TCAP options doesn't work (tcapquery.pl)
  • Updating the xterm title doesn't work (title.sh) - note that keithw#137 suggests that mosh provides a partial mechanism for this.

All the above tests were done using xterm-278 with FreeBSD as both client and server.

Owner

keithw commented Apr 13, 2012

Thanks very much for going through this.

I cannot reproduce the 16color issue on the current git master (post commit a67ae7b "Support 16-color set (per Anders Kaseorg)"). It seems to produce identical results for me in raw xterm vs. in mosh-in-xterm. Are you able to point me more specifically at the problem?

I do know we have some sort of bug involving renditions as produced by the zsh prompt, and we actually get different results in termemu vs. in full mosh! This is confounding and I will need to track this down over the next few days.

We have made a decision not to support initc (acolors, dynamic) for now, because support is so buggy and inconsistent in outer terminals. xterm seems to support it properly but is incredibly slow (it may make a synchronous X query on every initc). gnome-terminal is very buggy. Terminal.app ignores it completely.

We will fix the title problem and support OSC 2 (title.sh), thanks.

Contributor

peterjeremy commented Apr 13, 2012

I have a screenshot showing the 16colors.sh issue with the latest GIT version (as of now). How can I get it to you?

As well as the vttests subdirectory in xterm, there's also a vttest suite - http://invisible-island.net/vttest/vttest.html and I've tried running through those tests with the following results:

  • no 132 col mode
  • no "Character set 0 (Special graphics and line drawing)"
  • no double-width or double-height characters
  • linefeed/newline mode doesn't work
  • "Request Terminal Parameters" fails
  • "Known bugs" "Funny scroll region" only shows lines 1-19
  • DEC protected areas (DECSCA, DECSED, DECSEL) not supported
  • ISO-6429 Cursor-Back-Tab (CBT) fails
  • ISO-6429 Cursor-Horizontal-Index (CHT) fails
  • ISO-6429 Next-Line (CNL) fails
  • ISO-6429 Previous-Line (CPL) fails
  • ISO-6429 Repeat (REP) fails
  • ISO-6429 Scroll-Left (SL) fails
  • ISO-6429 Scroll-Right (SR) fails
  • xterm report fonts fails
  • xterm alternate screen fails
  • xterm cursor save/restore fails
  • xterm mouse reporting fails (the "links" web browser relies on this)

@keithw keithw added a commit that referenced this issue Apr 14, 2012

@keithw keithw Fix vttest "Funny scrolling regions" by ignoring some invalid scroll …
…regions

Addresses #155 github issue.
53f79e4
Contributor

peterjeremy commented Apr 14, 2012

Following investigation, the 16colors.sh issue is because mosh only supports 8-color and 256-color xterms and selects which based on the terminfo "colors" value - which isn't reliable on BSD. xterm allows you to query the number of colours with DCS + q 4 3 6 f ST but this can be disabled and doesn't work on other terminal emulators.

Owner

keithw commented Apr 14, 2012

Since we now only advertise TERM=xterm-256color when the original client supports colors>=256, I'm not sure we really need the posterization anymore. We could just pass through all 256color sequences that we happen to get. This would at least make that demo work properly for you.

@keithw keithw added a commit that referenced this issue Apr 14, 2012

@keithw keithw Disable posterization and rely solely on TERM to tell remote end abou…
…t colors

(should help #155 github issue)
a4221d1
Contributor

peterjeremy commented Apr 15, 2012

I misunderstood acolors.sh - it's actually dynamically changing the colourmap - which isn't a feature I see a great need for. Attribute changes are correctly reflected to the client.

Realistically, the features that are actually an issue for me are:

  • Dynamically changing terminal size
  • Independently setting terminal & icon name (which is in hand)
  • "Character set 0 (Special graphics and line drawing)"
  • Double-width & double-height characters (though as a low priority)
  • xterm cursor save/restore (I think I still use apps that depend on this)
  • xterm mouse reporting (the "links" web browser relies on this)
Contributor

kmcallister commented Apr 15, 2012

Thanks for telling us which features you need. We've thought about a few of these already.

Independently setting terminal & icon name (which is in hand)

Yep, that's committed as d0a818d.

"Character set 0 (Special graphics and line drawing)"

vttest enters line drawing mode by sending \e(0, after which ordinary ASCII codepoints are rendered as line drawing characters. Mosh deliberately avoids supporting these locking character sets, which cause the infamous "hieroglyphs" effect after a terminal eats some binary garbage. See also the Mosh website on this. You can encode any of the line drawing characters statelessly in UTF-8.

xterm mouse reporting

We're tracking this as #101. It seems rather annoying to implement, but we may do it eventually.

Owner

keithw commented Apr 16, 2012

We are tracking alternate screen at #2.

What is xterm save/restore? We do support the classical vt220 save/restore (ESC 7 and ESC 8), tested by vttest at the end of option 2 (Screen features).

You mentioned on IRC that the FreeBSD ncurses isn't honoring NCURSES_NO_UTF8_ACS -- which if it can't be fixed is cause for concern on our end. This has been in ncurses since 5.5 as best I could determine.

Contributor

peterjeremy commented Apr 16, 2012

The xterm save/restore issue is vttest (http://invisible-island.net/vttest/vttest.html) test 11.8.5.1. I've confirmed that ESC 7 ESC 8 works so this is presumably related to alternate screen handling and isn't an issue for me.

FreeBSD ncurses does support NCURSES_NO_UTF8_ACS. It's just that neither option gives line drawing characters via mosh. NCURSES_NO_UTF8_ACS=1 gives me boxes drawn with |+-. NCURSES_NO_UTF8_ACS=0 gives me boxes drawn with xlq etc.

Owner

keithw commented Apr 16, 2012

Can you please post "script" output from an ncurses program with NCURSES_NO_UTF8_ACS=1 so I can take a look and see what it's doing?

Ideally this typescript would display properly in xterm but wrongly in mosh...

Owner

keithw commented May 24, 2012

Closing as the last problem seems to be the way FreeBSD builds ncurses (vs. ncursesw) without UTF-8. We have emulated the rest of the escapes that we plan to emulate at this point, except (1) alternate screen switching and (2) mouse movements, which have their own separate issues.

Thank you again for this very helpful list.

keithw closed this May 24, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment