Open noseglid opened 8 years ago
Hi! Just a couple of days ago my pull request #5 received a friendly comment from @rgbkrk to look at the following fork: https://github.com/sourcelair/xterm.js
I haven't had time to check it out yet, but there certainly seems already some forks out there who have continued the journey...
I am also very interested in this to improve atom-build by @noseglid For example one thing i would really like to see is "cmd/ctrl" click to open a file like iTerm2 does on mac. @parisk do you think term.js could easily be switched to your fork? without too much code change?
I'm currently away during Easter but I'll make a list of all interested parties. It seems like there's a lot of usage of this project @chjj made and we all want a nice governed way to move forward. If we join forces I'm sure we can reach much farther than if we work alone!
@farfromrefug @noseglid we welcome outside contributions at xterm.js. We would be glad if you created any GitHub issues there about desired functionality and reviewing your PRs or even working on them together.
@parisk How far have have xterm.js diverged from term.js ?
@noseglid the main differences are:
Xterm.js can act as a front-end to almost any kind of terminal-based process. We use it at https://www.sourcelair.com, to grand access to full Linux environments to our users, where they also use vim, tmux, htop and other curses-based applications, besides typical bash commands.
Do you think that this can fit your needs?
Just for everyone's information, my project Extraterm contains a fork of term.js.
Main changes:
@sedwards2009 that looks awesome! Could you make a sample package for atom to test it? I have tested your osx app and it works well (wondering about antialiasing though as it does not look quite right) Especially there are 2 things which i really like which are the presence of the scrollbar and the ability to select while scrolling with the mouse. This is something no one seems to be able to achieve in atom. That's why i would love to test yours in atom
@farfromrefug I'm full on busy with Extraterm and don't the have the time to mess with a sample package for Atom. The best example code and way to test it is Extraterm itself. Atom and Extraterm both use Electron as their platform.
The scrollbar is not part of term.ts but is added by the GUI code around it. Extraterm actually uses CodeMirror to render the contents of the term screen. Lines which scroll out of the terminal also put into CodeMirror. CodeMirror gives me free mouse selections, and also a cursor with keyboard control.
The terminalviewer.ts
handles most of the work of displaying the contents of the terminal. That is where you should look if you want to get this into Atom. (Personally, I just want a separate terminal emulator.)
@sedwards2009 thanks i will try to package an example into atom! CodeMirror seems great! About a separate emulator, the idea is to be able to tie everything together, especially get the errors out of the terminal output so that atom-linter can show them.
Hi @noseglid,
It seems that Extraterm aims to be a native terminal replacement that spans across platforms. Xterm.js is a terminal component, which operates entirely into the browser, or any other browser-like environment like Electron apps.
So while merging does not make total sense for xterm.js, it could definitely be the terminal component of Extraterm, if @sedwards2009 sees value in it.
Last, I have also created the org https://github.com/xtermjs, in order to make xterm.js a standalone project in the future.
tl;dr: extraterm is a superset of both xterm.js and term.js and does not seem to work in the browser as-is. We, the maintainers of xterm.js, are more than open in collaborating with other projects and accepting external PRs.
Yes, Extraterm is intended to be a full terminal application. It does contain an emulator component deep inside which is originally term.js. As mentioned above, I'm made quite a lot of changes. A simple diff between Extraterm's term.ts
and term.js
will most likely show a huge number of changed lines.
At the moment my prio is on Extraterm in general but not term.ts
directly. It works quite well now and I don't have any major bugs which need to be fixed inside it. Future changes will probably be related to performance and of course fixing any bugs which are affecting applications. Implementing every last old obscure and unused terminal feature isn't a priority.
The point I want to make is that I'm happy with where term.ts
is and don't have much motivation to go change that situation for Extraterm at least. If other people want to take and extract term.ts
from the rest of the Extraterm code (probably not hard) and use it as a component, then they are welcome.
Hey guys, sorry I've been neglecting this project. Work always gets in the way for me. I actually agree with the changes @parisk mentioned. In retrospect, I think it was a mistake to add high level tmux+clipboard functionality to term.js. It belongs somewhere else.
I am okay with moving this project to a separate organization and adding owners (if @parisk wants to merge his changes -- I haven't looked over them but they sound reasonable). I likely won't be able to maintain this again for a while.
:+1: i'd vote for the org that @chjj is proposing and continue with this project, merging changes back from the forks...
That sounds great.
So does moving term.js to https://github.com/xtermjs and then start working with contributors make sense for you? Should we move forward with this?
I've been meaning to test out xtermjs but haven't found the time yet.
I think it makes a lot of sense creating that organization and moving stuff there. Who knows, maybe we can even get @chjj to participate :)
I'm definitely in to contribute in any way I can. I'll be looking to move my current usage (a commit from @jeremyramin's fork) to xtermjs.
I'm currently working on the integrated terminal for VS Code and just want to throw my :+1: in for action on this issue. I've run into a few problems with term.js and currently it seems like either forking it ourselves or going with one of the other forks is the only option if no movement is made on this issue (see https://github.com/Microsoft/vscode/issues/6838 for more context).
Any news on the organization idea @chjj /others? I'd be interested in contributing as well.
I am also very interested in this. Will need a good console in my electron apps. I would love to contribute too Let s go with this!
I am also very interested in this.
@chjj any chance to spin the org up and get traction with this? Cheers!
Hello everyone,
I am the main contributor of one of the forks of his repository (https://github.com/sourcelair/xterm.js), which is used in a few products already. We would love to have more contributors to this project and review issues and pull requests. Also, we have already created an organization, in case we decide to move development over there.
@Tyriar, @farfromrefug, @runner-mei do you believe that you could give a quick try to xterm.js in your projects and report any issues that might come up? It would be great if we could help people integrate it in other products as well.
Most of the API of Xterm.js is intentionally backwards-compatible with term.js, so evaluating it should not be a pain.
@parisk it's on my list of libs to investigate https://github.com/Microsoft/vscode/issues/6838 :smiley:
@parisk i am actually using it right now. Needs quite some testing though. BTW i am using it only as a console, not a terminal.
@Tyriar hello xterm.js and term.js what s the difference
xterm.js is actively maintained. There are a bunch of differences now; speed, language support, bug fixes, and so on.
Hi @parisk, I've an old project that uses term.js and i want to move it to xterm.js Any advice or the best way to migrate ? what are the main change to consider?
thanks
@rivelbab term.js' API is relatively small, you can check the major versions for what breaking changes were made over time:
https://github.com/xtermjs/xterm.js/releases/tag/2.0.0 https://github.com/xtermjs/xterm.js/releases/tag/3.0.0 https://github.com/xtermjs/xterm.js/releases/tag/4.0.0
I've been wanting to use this library for a few things and it works very well in many respects. It does feel a bit unmaintained at the moment though, which is a cause of concern.
I am be happy to start contributing and maintaining this. I'm guessing this issue is an open discussion around getting this back into an active development state.
People of interest, I think is: @chjj @jeremyramin If you know more who'd want to participate, bring them into the discussion.
What do you think?