The current trimming of lines cannot distinguish between inserted spaces and empty cells since it trims spaces. This is related and discussed in #1685, also #1769 is affected by this.

This PR is a testbed to evaluate the empty cell representation with a different char than space to overcome the drawbacks. It currently inserts an empty string instead, for TypedArray this automatically falls back to '\x00' (treated as '').

Although doing an additional char replace this is even faster with TypedArray than the current impl (tested with xterm-benchmark with https://gist.github.com/jerch/acca11c68bfe5c8172c909a1cb9fa6db):

• master:

   Context "examples/terminal_translateToString.perf.js"
      Context "translateToString - JSArray"
         Case "#1" : 1 - runtime: 96.65 ms
         Case "#1" : 2 - runtime: 32.21 ms
         Case "#1" : 3 - runtime: 30.18 ms
         Case "#1" : 4 - runtime: 28.49 ms
         Case "#1" : 5 - runtime: 26.41 ms
         Case "#1" : 5 runs - average runtime: 42.79 ms
      Context "translateToString - TypedArray"
         Case "#1" : 1 - runtime: 64.41 ms
         Case "#1" : 2 - runtime: 65.35 ms
         Case "#1" : 3 - runtime: 42.41 ms
         Case "#1" : 4 - runtime: 43.92 ms
         Case "#1" : 5 - runtime: 37.30 ms
         Case "#1" : 5 runs - average runtime: 50.68 ms

• this PR:

   Context "examples/terminal_translateToString.perf.js"
      Context "translateToString - JSArray"
         Case "#1" : 1 - runtime: 93.65 ms
         Case "#1" : 2 - runtime: 30.70 ms
         Case "#1" : 3 - runtime: 37.63 ms
         Case "#1" : 4 - runtime: 34.29 ms
         Case "#1" : 5 - runtime: 32.54 ms
         Case "#1" : 5 runs - average runtime: 45.76 ms
      Context "translateToString - TypedArray"
         Case "#1" : 1 - runtime: 45.00 ms
         Case "#1" : 2 - runtime: 29.49 ms
         Case "#1" : 3 - runtime: 24.42 ms
         Case "#1" : 4 - runtime: 38.41 ms
         Case "#1" : 5 - runtime: 24.89 ms
         Case "#1" : 5 runs - average runtime: 32.44 ms

Why bothering at all, doesnt it work as it is? Well we have several issues open that boil down to this problem. All consumers of Buffer.translateBufferLineToString with trimming enabled are affected by this. It gets even worse when a consumer tries to unwrap lines, esp. if a resize was done in between (resizing itself is a different problem though that will be addressed with reflow).

Edit: The canvas renderer seems to be faster too, the time for ./lib/renderer/TextRenderLayer.js.TextRenderLayer._forEachCell dropped from ~ 350 ms to ~ 220 ms (tested in chrome, to lazy to write a xterm-benchmark case). Any idea why? (I am not familiar with the code) Was due to wrongly skipping empty cells...

Would be good to get some early feedback before going down the rabbit hole (yeah it is likely to affect several parts of the code base).