Reflow doesn't work

[svenefftinge]

I tried to get the new reflow support (#1864) enabled but don't know how. @Tyriar mentioned

Note that this only works when the TypedArray buffer is enabled.

Could you tell me how to do that?
When automating the resize for the demo it behaves like below:

Here's the gitpod workspace from the gif to reproduce:

[mofux]

The pure demo without login to Gitpod can be found here: https://3000-e2881ed9-8762-4946-afe1-48d0f11b255f.ws-eu0.gitpod.io

My guess is that it's happening because the prompt input line is reflowed by the pty itself, and we are putting our reflow mechanism on top, which causes this strange behavior. You can see in the capture that the (real) prompt line is always preserved and correctly reflowed.

If you ls -alh inside that terminal, you can see that its output is also correctly reflowed.

@Tyriar Any thoughts?

[AndrienkoAleksandr]

My guess is that it's happening because the prompt input line is reflowed by the pty itself,

@mofux seems You are right:

On each resize pty send prompt update.

[Tyriar]

@svenefftinge the typed array buffer is the only option now and it's on by default because of this line in the release notes: "Removed old js array-based buffer implementation"

My guess is that it's happening because the prompt input line is reflowed by the pty itself

The line containing the cursor remains untouched by reflow, also all other terminals I've looked at act similarly to this when wrapping the prompt line so I think we're behaving correctly. Debouncing resize should also help with this as it will prevent issues around race conditions where the pty size and xterm.js size are out of sync, I added a note to the resize method to call this out:

https://github.com/xtermjs/xterm.js/blob/3.11.0/typings/xterm.d.ts#L445

[svenefftinge]

Ok, thanks I will try that.

[Tyriar]

Np, @mofux found #1944 after discussing this 👌

[akosyakov]

It's still an issue in 3.12 on master. In order to reproduce with xtermjs

@Tyriar Could it be reopened?

[Tyriar]

@akosyakov tracking the remaining crash in #1932

[akosyakov]

Actually i'm not sure it is #1932. I can reproduce it with an example by changing cols between 10 and 80. Each time more and more lines appear but no errors in console like in #1932.

[Tyriar]

@akosyakov the errors in #1932 are just one of the errors that could happen if the buffer numbers are invalid, I think it just depends on what is run after the corruption occurs.