-
Notifications
You must be signed in to change notification settings - Fork 74
Update to work with xtermjs 4 #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@wavesoft would you be able to take a look at this? |
Hello and thanks for the PR @coolreader18 ! Will have a look now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @coolreader18 !
I tried this with the v3 API and it's not working, so I proposed a few changes. Plus, what do you think about maintaining the old LocalEchoController
constructor interface?
@@ -36,12 +36,19 @@ export default class LocalEchoController { | |||
this._cursor = 0; | |||
this._activePrompt = null; | |||
this._activeCharPrompt = null; | |||
this._termSize = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a good practice towards V8 optimisation it's a good idea to describe the object shape in the constructor and avoid mutating it later. So I would vote for keeping some defaults here, like so:
this._termSize = {
cols: 0,
rows: 0
}
const localEcho = new LocalEchoController(term); | ||
// Create a local echo controller (xterm.js >=v4) | ||
const localEcho = new LocalEchoController(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think instead of breaking the API (in order to maintain some seamless migration from v3 to v4) to move this detection in the constructor?
For instance:
if (!term.onData) {
// We are dealing with v4 API
} else {
// We are dealing with v3 API
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd think that people using this library would be the ones specifying the version of xterm that they're using, and even if they aren't, passing the terminal to the constructor should still work even in v4.
It looks as if the reviewer suggestions have been applied in the latest commit. Can we expect this PR to be merged soon? |
is it ready for xtermjs 4.x ? can't find a release working with xtermjs 4.x |
How about ditching support for older xtermjs versions altogether? An older version of local-echo can be used with an oder xtermjs, but there is currently no version of local-echo that works with the current version of xtermjs. |
I just installed the branch from github and it's working great. |
I concur - I suggest a merge. |
@wavesoft @coolreader18 any update on this? looking to get a local-echo working with xterm >= v4 |
@jasonolmstead33 I suggest installing from the branch instead of the main repo. 😁 |
@RangerMauve thats what ive done for now, thanks, hoping we can get it as part of master :) |
Hey guys! Sorry for the long absence, going to land this, run some checks and cut a new release 👍 |
@wavesoft It looks like release hasn't been cut yet? |
@wavesoft Ping. Can you please at least add a prebuilt version to the repo? For now I can do |
This should still be compatible with xterm v3, though I haven't actually tested it. The
onData
andonResize
methods have been there for a while (typescript typings for xtermjs 3.14), and in theory even the new addon system could be used in xtermjs 3.14, though the old way of passing a terminal to the constructor still works.