atom-domterm's Introduction

atom-domterm

an Atom package for the DomTerm terminal emulator

DomTerm is a terminal emulator/multiplexer with lots of nice features. Most notably you can embed graphics/html, and session management is included. See http://domterm.org for more about DomTerm.

The atom-domterm package requires the domterm command to be in your PATH. (If not, edit the domtermCommand variable in lib/domterm-view.js.) The domterm command runs as a server, which provides session (pty) management, and serves up the needed JavaScript and styles. Apart from the domterm application, atom-domterm requires no native code or extra packages.

To run atom-domterm, place a link to the atom-domterm directory in ~/.atom/packages. Then DomTerm should come up in the Atom Packages menu.

Note there is already an Electron wrapper for DomTerm, which works very well. That is included in the DomTerm sources, and is the default user interface for DomTerm.

The atom-domterm package has only been tested on Fedora 27. Most functionality works pretty well, though more testing is needed.

Features

A solid modern terminal emulator. Mouse handling; 24-bit color; encodes special keys. Good xterm compatibility and does very well on the vttest test suite. Good Unicode support, including wide characters.
Integrates well with the Atom pane system. The screenshot show 3 sessions, named "DomTerm:1" (default name) plus "compile" and "run" (in an inactive tab). The "window title" of the active terminal is displayed both in the message area and in the main title bar.
Error message from many compilers are turned into clickable links. The compile pane of the screenshot show the effect of mouse hover over the warning - note the corresponding file URL in the message area. Clicking on the link is customizable - the default opens an atom editor tab positioned at the corresponding line.
You can "print" graphics or general HTML. This makes domterm suitable as a "graphing calculator". The screenshot show an image "printed" by the domterm imgcat command. Gnuplot can display graph output inline. You can have the man command print HTML to the console. Many other possibilities.
You can style the terminal using CSS. This is usually done in ~/.domterm/settings.ini, which is automatically reloaded when saved. The screenshot shows how you can set terminal-specific background colors.
Remembers tab characters and distingishes explict new-line from line-wrap. So you can cat a Makefile, and then copy-and-paste it. Lines are re-wrapped on terminal re-size.
The basic "session management" functionality of tmux or GNU Screen: You can detach and re-attach session.
Builtin optional line-editor (like a simplified readline).
Builtin optional pager (like a simplified less).

atom-domterm's People

Contributors

Stargazers

Watchers

atom-domterm's Issues

stylesheet

It'd be sweet if there was something like the Application: Open Your Stylesheet but for atom-domterm styling (because it is in a frame, so obviously Atom stylesheet won't do anything).

Crashes on opening

Crashes on opening, whether trying to open view or split into pane.

Atom 1.31.2 64 bit (current)
Mac OS X High Sierra

use webview or iframe?

Depending on the usingWebview variable, atom-domterm can use either a <webview> or an <iframe> for the embedded terminal emulator. Currently, it works better with <iframe> (usingWebview is false), so that is the default. The main problems with using <webview> are:

Serialization with <webview> isn't working - which causes lots of problems. I don't know why - it could be related to the DomTermView class not extending View. (I haven't figured out how to do that in plain JavaScript.)
The Atom keybindings override DomTerm's handling of key events. Given that a terminal emulator needs to handle most keybindings on its own, this is a problem. The keymaps/domterm.cson file fixes some of the problems, but it would be better for the default to be native. (I can't get native-key-bindings to work.) Using an <frame> handles this by default.

On the other hand, there are some things using <webview> with node integration handles better than <iframe>. I've been fixing various <iframe> problems but it seems to be fighting the system.