wcwidth calculation

[jerch]

Quick replacement of isWide() with wcwidth. Since xterm.js has no frontend packaging atm I just copied my version into the source file.

wcwidth fixes several issues:

• full unicode (all planes supported at data stage, output depends on font capability)
• combining characters
• half/fullwidth distinction for all unicode codepoints (though lookup table needs fixes to get xterm or font compatibility)

Misaligned glyphs are not fixed by this pull request. This would need a way to introspect the current font and glyph widths. This could be done by prerendering faulty glyphs onto a canvas, getting their width with measureText and aligning them with a CSS rule. I played with this approach here https://github.com/netzkolchose/jquery.browserterminal/blob/master/dist/js/jquery.browserterminal.js#L289, the glyph width calculation is pretty slow but is only needed once.

[parisk]

Hi @jerch, thanks for your contribution! Before moving on with testing this out, could you please mention the particular GitHub issues that this PR is supposed to fix?

[jerch]

Issues affected by this: #72 , maybe #70 , #62

and yeah, imho xterm.js needs some more test cases...

[Tyriar]

Where was this list sourced from?

[jerch]

Extracted from here https://www.cl.cam.ac.uk/%7Emgk25/ucs/wcwidth.c

[jerch]

I have cleaned up the code and fixed the indentation.

[Tyriar]

Thanks @jerch! I'll have to take a chunk of time to look at this in detail, can you think of some test cases that could be added for wcwidth?

[jerch]

yes I have some test cases, gonna try to apply them to xterm.js.

There are some edge cases that need proper testing:

• fullwidth chars just go to next line if entered at cols-2, what to do with the last cell itself? It will need at least the attributes set.
• combining chars should go to last active cell - needs tests for all cells, no clue yet how solve this after cursor jumps (xterm just insert them at the cursor after jumps)

Offtopic:
Also the rendering needs some fixes, the fullwidth chars are not cell aligned for most of my fonts.

[jerch]

One test case fails - I commented it out since the it refers to a missing feature in default state (wrap true/false is not handled there at all). --> see #147

[parisk]

Okay, just found the chance to take a deeper look into this. #72 does not seem to be closed by this (still weird characters appear, but different than the ones mentioned in this issue).

This PR closes #70 and closes #62 successfully though.

I will move on with merging this PR, since it great steps forward have been done here. I also believe that #72 can be tackled autonomously, since it appears only when moving the cursor.

Thanks a lot!