Work together to make term.js greater

[noseglid]

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?

[exsilium]

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...

[parisk]

Hi everyone! I am one of the maintainers of xterm.js. Ee would be more than happy to work with you, in order to introduce functionality to xterm.js that suits your use cases.

We are really open to outside contributors and maintain this repository actively.

[farfromrefug]

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?

[noseglid]

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!

[parisk]

@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.

[noseglid]

@parisk How far have have xterm.js diverged from term.js ?

[parisk]

@noseglid the main differences are:

• we ripped off all screen/tmux like functionality, in order to leave this completely to the actual terminal (it could be re-implemented as an add-on though)
• we replaced its I/O mode with a hidden textarea, but this will change in the short-term future for an even more robust implementation
• made the terminal themeable (no hardcoded styling)
• offloaded some functionality to add-ons

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?

[sedwards2009]

Just for everyone's information, my project Extraterm contains a fork of term.js.

Main changes:

• Converted it all to TypeScript.
• Separated the emulation part from the rendering.
• Optimised the rendering, i.e skip scrolling when the term is being spammed, much much faster
• CSS classes for styling
• Code organisation
• hooks for expanding the escape codes with custom ones.
• random bug fixes.
• some more character attributes / styles
• screen / tmux stuff is dead

[farfromrefug]

@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

[sedwards2009]

@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.)

[farfromrefug]

@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.

[noseglid]

I haven't made any additions to term.js yet, so I'm possible the worst person to coordinate a joint effort. That said:

It seems as the two most active are

• Extraterm
• xterm.js

@sedwards2009 , @parisk would you be interested in trying to merge the two codebases together and continue with one project?

[parisk]

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.

[sedwards2009]

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.