I just pressed that button to see if it works, turns out I can actually do canary releases. Since sooo much has improved since the last one, I think we can let it stay up and collect some feedback on it.
Hi !
Very nice to see a new canary release 🎉
My cursor is hidden with this canary. I tried to change my config (cursor type and color) without any success. Issue tracked here: https://github.com/zeit/hyper/issues/4195
We have an issue with the version and the tag. They are desync. Update is redownladed each time

Yeah because release did not bump the version in the app
Text selection doesn't work anymore: https://github.com/zeit/hyper/issues/4196
Unpublished the release for now :)
@Stanzilla @chabou
From what I see the main issues we saw in the release are
Cursor and Selection colour (#4195 and #4196 )
and
Unicode characters in $PATH on Windows (#4190 )
I'm listing possible solutions (a little hacky) which should help us for the time being.
For the colour issue, as mentioned by @ivanwonder https://github.com/zeit/hyper/issues/4195#issuecomment-577970104 the issue is fixed in xterm master and would be there in the next release 4.4.0
which is at least 10 days away, but we can use the latest beta build (tested ok). We can use the stable build once it releases.
For the Unicode issue, I was able to get the values properly using 'registry-js', but it doesn't seem to have a way of setting values https://github.com/zeit/hyper/issues/4190#issuecomment-578055899
I tried to do a mix of 'winreg' and 'registry-js', i.e. using registry-js to read PATH and winreg to set the value (tested ok). You can see the code here. We should try to get a proper fix, but this should get us moving.
I think with this we should be able to do a new canary release and thus be able to get to know about any other issues when people use it.
Thank you for the investigation! I think we should use the 10 days to maybe come up with a better solution for the registry thing and then do a new canary release with the new xterm.
For example the awesome @eugeny made this for use in Terminus https://www.npmjs.com/package/windows-native-registry maybe we can use it as well
@LabhanshAgrawal If use the latest beta build of xterm, Split Horizontally and Split Vertically can't work.
Hmm.. there seems to be some issue. Thanks for pointing out, I had only checked for the color issue.
The split is happening but with a plugin error notification and the following errors in console
term.js:115 Uncaught TypeError: Cannot set property 'className' of undefined
at Term.componentDidMount (term.js:115)
at commitLifeCycles (react-dom.development.js:22101)
at commitLayoutEffects (react-dom.development.js:25344)
at HTMLUnknownElement.callCallback (react-dom.development.js:336)
at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
at invokeGuardedCallback (react-dom.development.js:440)
at commitRootImpl (react-dom.development.js:25082)
at unstable_runWithPriority (scheduler.development.js:697)
at runWithPriority$2 (react-dom.development.js:12149)
at commitRoot (react-dom.development.js:24922)
term.js:437 Uncaught TypeError: Failed to execute 'removeChild' on 'Node': parameter 1 is not of type 'Node'.
at Term.componentWillUnmount (term.js:437)
at callComponentWillUnmountWithTimer (react-dom.development.js:21896)
at HTMLUnknownElement.callCallback (react-dom.development.js:336)
at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
at invokeGuardedCallback (react-dom.development.js:440)
at safelyCallComponentWillUnmount (react-dom.development.js:21903)
at commitUnmount (react-dom.development.js:22392)
at unmountHostComponents (react-dom.development.js:22860)
at commitDeletion (react-dom.development.js:22896)
at commitMutationEffects (react-dom.development.js:25323)
md5-99870c98ce46dadd5b69c890ac8100b2
backend.js:6 The above error occurred in the <Term> component:
in Term (created by _exposeDecorated(Term))
in _exposeDecorated(Term) (created by DecoratedComponent)
in DecoratedComponent (created by TermGroup_)
in TermGroup_ (created by ConnectFunction)
in ConnectFunction (created by Connect(TermGroup_))
in Connect(TermGroup_) (created by _exposeDecorated(TermGroup))
in _exposeDecorated(TermGroup) (created by DecoratedComponent)
in DecoratedComponent (created by TermGroup_)
in div (created by SplitPane)
in div (created by SplitPane)
in SplitPane (created by _exposeDecorated(SplitPane))
in _exposeDecorated(SplitPane) (created by DecoratedComponent)
in DecoratedComponent (created by TermGroup_)
in TermGroup_ (created by ConnectFunction)
in ConnectFunction (created by Connect(TermGroup_))
in Connect(TermGroup_) (created by _exposeDecorated(TermGroup))
in _exposeDecorated(TermGroup) (created by DecoratedComponent)
in DecoratedComponent (created by Terms)
in div (created by Terms)
in div (created by Terms)
in Terms (created by _exposeDecorated(Terms))
in _exposeDecorated(Terms) (created by DecoratedComponent)
in DecoratedComponent (created by ConnectFunction)
in ConnectFunction (created by Connect(DecoratedComponent))
in Connect(DecoratedComponent) (created by Hyper)
in div (created by Hyper)
in div (created by Hyper)
in Hyper (created by _exposeDecorated(Hyper))
in _exposeDecorated(Hyper) (created by DecoratedComponent)
in DecoratedComponent (created by ConnectFunction)
in ConnectFunction (created by Connect(DecoratedComponent))
in Connect(DecoratedComponent)
in Provider
React will try to recreate this component tree from scratch using the error boundary you provided, DecoratedComponent.
r @ backend.js:6
md5-99870c98ce46dadd5b69c890ac8100b2
notify.ts:4 [Notification] Plugin error: Plugins decorating Term has been disabled because of a plugin crash. Check Developer Tools for details.
Thank you for the investigation! I think we should use the 10 days to maybe come up with a better solution for the registry thing and then do a new canary release with the new xterm.
For example the awesome @Eugeny made this for use in Terminus https://www.npmjs.com/package/windows-native-registry maybe we can use it as well
I tried out 'windows-native-registry'.
It was able to read the values correctly, but it messed it totally while setting the value. 'winreg' messed the unicode characters only, but this ends up setting some totally unrecognizable value.
My path looked like this initially
C:\Users\labha\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\labha\AppData\Local\Programs\Python\Python38\;C:\Users\labha\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Microsoft VS Code\bin;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;C:\Users\labha\AppData\Roaming\npm;C:\Users\labha\AppData\Local\Yarn\bin;
And I tried to add Iñtërnâtiônàlizætiøn☃💩 to it ref
And ended up with this
when I add it manually it's able to read it correctly, but clearly can't set it.
Hrm, did you look at how it's implemented in Terminus? Maybe @eugeny can help?
I just now looked at Terminus code and it seems to only be getting used there to set the context menu entries, and the values are regular strings.
I found https://github.com/ironSource/node-regedit, takes some extra steps because of ASAR though.
xterm 4.4.0 is out now, also coming with xterm-addon-unicode11 which we should probably use
@Stanzilla @chabou
From what I see the main issues we saw in the release are
Cursor and Selection colour (#4195 and #4196 )
and
Unicode characters in $PATH on Windows (#4190 )I'm listing possible solutions (a little hacky) which should help us for the time being.
For the colour issue, as mentioned by @ivanwonder #4195 (comment) the issue is fixed in xterm master and would be there in the next release 4.4.0
which is at least 10 days away, but we can use the latest beta build (tested ok). We can use the stable build once it releases.For the Unicode issue, I was able to get the values properly using 'registry-js', but it doesn't seem to have a way of setting values #4190 (comment)
I tried to do a mix of 'winreg' and 'registry-js', i.e. using registry-js to read PATH and winreg to set the value (tested ok). You can see the code here. We should try to get a proper fix, but this should get us moving.I think with this we should be able to do a new canary release and thus be able to get to know about any other issues when people use it.
@Stanzilla
The only remaining issue now is the Unicode in PATH
I looked at node-regedit, but have never used asar, so it'll take some time for me to try it out. Did you try it?
I sadly have not, too much work work recently. I think we already include a file outside of asar for the CLI stuff though? Should be the same principle, afaik
hm, will have to check that out.
https://github.com/zeit/hyper/blob/canary/electron-builder.json#L7
This should be the trick
What about #3929?
right, that one as well
we should add all the blocking issues to the milestone for 3.1.0
Done. Btw I would have given you contributor permissions ages ago but I don't actually have enough permissions myself to do it :/
Done. Btw I would have given you contributor permissions ages ago but I don't actually have enough permissions myself to do it :/
no worries 😊
can't deny I would love that though 😜
we can close #4195 and #4196 as it's fixed with the xterm update
also we can move #3575 and #3778 to 3.2.0 milestone as it's about the webgl renderer.
Published a new canary release for mac and Linux, let's see how it goes.
The release assets doesn't have files for Windows
That's why I said I published it for mac and Linux :D
Oops my bad 😐Just saw the release and noticed that, didn't read your comment fully.
Why no release for Windows though? You noticed any new issue?
No, the cert on appveyor is still broken so it can't build it
@Stanzilla now that all the issues in the 3.1.0 milestone have been closed I think we should do a 3.1.0 canary 5 release and then based on the response after a few days release 3.1.0.
Yeah I was kinda waiting for the new xterm release. Not sure how Corona affected that, @Tyriar any ETA for it?
are there any particular changes we're waiting for? If it's ok we can release canary 5 now and do one more with the new xterm before stable release. Would be better to get new feedback since all blocking issues are fixed now.
Not but since we're waiting on the cert for appveyor anyway I figured why not.
I see, maybe mac and linux only like canary 4 now and hopefully if the cert is there by the time xterm releases then one more?
Yeah I was kinda waiting for the new xterm release. Not sure how Corona affected that, @Tyriar any ETA for it?
4.5.0 milestone mentions April 3
Mostly settings sync in vscode that caused the delay -> https://twitter.com/Tyriar/status/1242085047404019716
@Stanzilla was the appveyor cert updated? If yes we can release now.
Nope
I'm still waiting for this release 😔
So are we
Most helpful comment
Unpublished the release for now :)