Most promising terminal extension


#1

I would be so happy if atom had a full-featured terminal included. It looks like there are no really mature terminal packages yet, but I’m wondering which is the most active to potentially contribute to.

The main options appear to be:
(the no longer maintained atom terminal)

Termrk

Term2

I would consider trying to add support for remote terminals (although I don’t really know what I’m doing), but I’m wondering if there is a clear consensus in the atom community about which terminal package is the way forward.


#2

Another option that seems active.


#3

Terminal-package is targeting at quickly running some commands. Like if you don’t want to set up a build system, but want to be able to just grunt something. It doesn’t feature many things you would expect from a terminal and it will take an entire overhaul to change that.

Term2 is the most mature and reliable one I’ve seen. I was able to just use the fish shell I’m used to from within Atom. It only crashed when I used it to run a program that would output messages continuously, and even then it ran fine for hours.


#4

I think termrk has been looking like the most promising so far for me; there are still some bugs but they seem to be worked on a lot. The key feature that made it useful for me was a key binding to send selected text to the terminal. This is a big bonus for me over the offerings of Term2, but if this could be added there that would be awesome.

I couldn’t get REPL-term (https://atom.io/packages/repl-term) running, but it also looks really good; this however is for launching terminal as a separate app (instead of an emulated terminal) with key bindings to send selected code for evaluation (which I think is maybe more desirable than an emulated terminal).

Sadly, there isn’t anything that works perfectly at the moment, certainly nothing on the level of the interactive shell in emacs. But hopefully soon!


#5

It should also be taken into account that Unix terminals are significantly different from windows ones: fundamentally, windows only offers its own cmd window as a terminal. Everything else will need to use system hooks and hacks to achieve decent functionality. See ConEmu to see what I mean.


#6

Define “decent functionality,” please. Not trolling, genuinely curious what you mean.


#7

I admit, I have no idea what it takes to get something like this set up and working in Windows. I suppose a solution to hook into the default OS X terminal doesn’t really have a good analogue there.


#8

By decent functionality I mean changing colors, moving cursor, overwriting the buffer and all that on Unix is handles by vt100 control codes. Try using something like the old QBASIC in the terminal emulator provided by cygwin and you’ll see what I mean.


#9

Ah. That stuff is there in recent windows versions, I think.

…time elapsing…

Just checked, looks like ANSI.SYS was responsible for that stuff in 16 and 32-bit MS operating systems all the way up to Win7, but for 64-bit MS operating systems there doesn’t appear to be any equivalent.

So, some JS terminal emulator would be needed to be cross-platform.

edit: I was again wrong. The Win32 API supports everything ncurses would need, but, of course, it’s a Win32 API and doesn’t really fit into something that an Atom developer would write. JS terminal emulator would be best, I think.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx <-- the API in question.


#10

Not sure of what you’re referring to, but I’m sure windows has never handled terminals the Unix way. In windows, the terminal window is part of the kernel, and the only way of getting an accurate representation of what’s in it is by doing some low-level winapi trickery. ConEmu does it, as I said. Unfortunately, it’s not the most elegant code ever written, and the Russian comments don’t really help in understanding what’s going on… So, on Windows, you can only get a partially working terminal without eventually going crazy.