The new version enables the mouse function in VIM mode: after set mouse = a, the mouse click character is no longer highlighted

[yoyo-milktea]

I recently updated the version to 4.14.1. The previous version was 3.14.4. The new version is in VIM mode: set mouse = a enables the mouse function, the click character is no longer highlighted, and the mouse pulley event is also prohibited. Is this the new version that removes these functions or can be enabled through settings?

[jerch]

You are prolly missing the onBinary event from xterm.js, which is needed to transport legacy mouse reports.

[yoyo-milktea]

Can you show me how to use it? I don't know how to use what you said

[yoyo-milktea]

You are prolly missing the onBinary event from xterm.js, which is needed to transport legacy mouse reports.

It used to work without extra settings, but now it doesn't work. I don't know what to do.

[jerch]

You use it like the onData event, but as bytestring, thus you should not try to convert it with UTF-8. E.g. with node-pty:

term.onBinary(data => pty.write(Buffer.from(data, 'binary')))

Also see https://xtermjs.org/docs/guides/encoding/#output.

[yoyo-milktea]

You use it like the onData event, but as bytestring, thus you should not try to convert it with UTF-8. E.g. with node-pty:

term.onBinary(data => pty.write(Buffer.from(data, 'binary')))

Also see https://xtermjs.org/docs/guides/encoding/#output.

Is the pty import from 'node-pty'?And the Buffer import from 'buffer'? Why does the new version of this function need to be accessed and written by itself? How good is the internal processing as before. Now the plug-in is more cumbersome to use

[jerch]

The old way led to faulty input at app side due to an implicit UTF8 conversion of mouse reports. The new way circumvents this by splitting data sent from the terminal into onData (normal string data, can be UTF8 encoded) and onBinary (cannot be UTF8 encoded). Without showing some code I cannot help you further beside the general advises. In the example above pty is the object returned from spawn and Buffer is nodejs' buffer type.

[yoyo-milktea]

The old way led to faulty input at app side due to an implicit UTF8 conversion of mouse reports. The new way circumvents this by splitting data sent from the terminal into onData (normal string data, can be UTF8 encoded) and onBinary (cannot be UTF8 encoded). Without showing some code I cannot help you further beside the general advises. In the example above pty is the object returned from spawn and Buffer is nodejs' buffer type.

oh,I am sorry about that.I use it according to the official examples. import { Terminal } from 'xterm'; import { FitAddon } from 'xterm-addon-fit'; this.term = new Terminal() this.fitAddon = new FitAddon() this.term.loadAddon(this.fitAddon) this.fitAddon.fit() this.term.onData(data => { ...... }) this.term.onBinary(data => { this.term.onBinary(data => pty.write(Buffer.from(data, 'binary'))) }) Prompt：Cannot find name 'Buffer'/'pty' I don't know what to do next.

[jerch]

Well you shortened the interesting parts - what do you do for onData? Same needs to be done for onBinary, but without UTF8 conversions down the road to the PTY.

[yoyo-milktea]

this.term.onData(data => { this.socket.send(JSON.stringify({data})) }) I just to send message to the server by websocket，no complicated operation was done. I'm sorry, my code is on the intranet. I can't take a screenshot to show you. I don't know if you understand the problem I want to express. It's difficult to express the problem without GIF diagram. Generally speaking, my usage is the same as the old version, but in VIM mode, using: set mouse = a, the click character of the mouse is no longer highlighted and the scroll wheel will not slide down.

[jerch]

Ok, so you prolly send the data to the server with a websocket? Then do the same with onBinary. Most likely you need to treat the data from onBinary differently on server side to avoid the UTF8 conversions, example:

// client side
// we use type='binary' to distinguish normal string data from binary data
this.term.onBinary(data => { this.socket.send(JSON.stringify({data, type: 'binary'})) })

// server side with nodejs and ws
// ptyObj is your pty object from node-pty.spawn
ws.on('message', msg => {
  const payload = JSON.parse(msg);
  if (payload.type && payload.type === 'binary') ptyObj.write(Buffer.from(payload.data, 'binary'));
  else ptyObj.write(payload.data);  // this does an implicit UTF8 conversion we try to avoid
})

If you dont use nodejs on server side you have to do it likewise - pass the bytestring as bytes to the PTY (refer to your server env how to do that).

Edit: Websocket also supports binary transport directly, maybe you can use that to your advantage avoiding the JSON re-packaging.

[yoyo-milktea]

Thank you very much.What I do is to simulate the Linux terminal interface through websocket and xterm.js.But my current system is separated from the front-end and back-end. I am only responsible for front-end development. I don't understand the server. Is there a way to achieve the effect I want without node processing? Do you know the effect I want?

[jerch]

I don't understand the server.

Then you will have to coordinate that with your backend devs.

Is there a way to achieve the effect I want without node processing?

You can do that in any backend system normally, e.g. in python you can send binary data to the PTY from JSON strings by doing something like this: ptyObj.write(json.loads(msg)['data'].decode('ascii'))

Do you know the effect I want?

Yes, you can actually test it in the demo app (which forwards onBinary correctly under linux/macos).

[yoyo-milktea]

Ok,I will try to coordinate it with my backend devs. Thank you very much.

[yoyo-milktea]

Hello, I forgot to tell you that I solved the problem I asked you a few days ago. In fact, my backend can handle binary stream data, but I didn't send the data of mouse events through websocket.

this.term.onBinary(data => {
    this.socket.send(JSON.stringify({data}))
})

Anyway, thank you very much.

[Tyriar]

Thanks, created https://github.com/xtermjs/xterm.js/issues/3529 as I notice it's not handled in the demo.