Prague Discussion

[Tyriar]

This is an issue capturing the discussion @mofux and I had in Prague. We can pull this into individual issues after any discussion.

Split frontend and backend

The idea here is to improve the overall code quality (particularly in Terminal.ts) and also allow monaco or a native UI to be used as a frontend more easily (eventually):

• We should move everything that touches the DOM into a Frontend object.

• Frontend owns a backend, this should change how terminals are constructed:

  const term = new Terminal(); // Backend
  const termFrontend = new TerminalDomFrontEnd(term);

• We could do it this way instead and maintain backwards compatibility, but even if you used a custom frontend you would need to include the code for the default one:

  class Terminal {
      open(elementOrFrontend: HTMLElement | ITerminalFrontEnd);
  }

  Also, the terminal knows about the frontend in this case.

• An ITerminalBackend interface, which ITerminalFrontend depends on, could look like this:

  interface ITerminalBackend {
      write(data: string): void;
      keyevent(event: ITerminalKeyEvent);
      mousemove(event: ITerminalMouseEvent);
      mousedown(event: ITerminalMouseEvent);
      mouseup(event: ITerminalMouseEvent);
      resize(cols: number, rows: number);
      onResize: Event<...>;
      // No wheel since that's handled entirely in the frontend
  
      // The backend should fire events that the frontend can listen to for
      // things like entering and leaving application/mouse mode (which the 
      // frontend needs to know about for things like wheel/selection handling)
  }

• Keyboard events in Terminal should be translated to an xterm event before sending it to _evaluateKeyEscapeSequence, the InputHandler, etc.

• Mouse events should also be translated

• These steps could be done incrementally as time allows and would eventually allow us to have much higher quality tests that test just the terminal backend, without worrying about the DOM and the complexities that come with testing that.

Web workers

The terminal backend is a good candidate to eventually live in a web worker, as opposed to just the parser that was the thinking before.

Viewport vs full buffer data

If the backend lives in a webworker, there needs to be a decision whether we want to only send viewport data or if the frontend should own the entire buffer.

[Tyriar]

Here's an example of an incremental step in this direction; pulling CompositionHelper into the frontend:

export class DefaultFrontend implements ITerminalFrontend {
  private _compositionHelper: ICompositionHelper;

  constructor(
    private _backend: Terminal
  ) {
    // TODO: This should own compositionView
    this._compositionHelper = new CompositionHelper(this._backend.textarea, (<any>this._backend)._compositionView, this._backend);

    on(this._backend.textarea, 'compositionstart', () => this._compositionHelper.compositionstart());
    on(this._backend.textarea, 'compositionupdate', (e: CompositionEvent) => this._compositionHelper.compositionupdate(e));
    on(this._backend.textarea, 'compositionend', () => this._compositionHelper.compositionend());
    this._backend.on('refresh', () => this._compositionHelper.updateCompositionElements());

    // TODO: Send compositionHelper key events
    this._backend.on('prekeydown', ev => this._compositionHelper.keydown(ev));
  }
}

[Tyriar]

@mofux it occurs to me that with this frontend idea we could also split the project into modules like this:

xterm (provides current API)
|- xterm-dom-frontend (works only in browser)
|  |- xterm-core (peer dep)
|- xterm-core (works completely in node.js or browser, prevents access to browser-specific APIs)

That way the xterm module provides the current API as a facade on top of the other modules? We could still keep them in the same repo if we wanted, but they would use different tsconfig.json files. Also only provide a stable API for the xterm module.

TS v3 would likely simplify this build process a lot: #1337

Or if we take the xterm-base idea from custom addons:

xterm
|- xterm-dom-frontend
|  |- xterm-base (provides interfaces needed for frontend only)
|- xterm-core
   |- xterm-base

[Tyriar]

I think everything in here is captured by #1507 and #1515