applying and diffing is nothing a Buffer should care about.

TermDiff is old and its functionality overlap with .apply() and .diff(). It should be replaced by a new implementation based on functions described above. API proposal:

• new TermDiff(term1, term2) should diff two terminals and create a diff-class of both.
• TermDiff.apply(term1) will apply itself to a given terminal.

This will change the API and therefore it will be targeted to 0.2

Currently, a few tests fail with Internet Explorer 8. It seems this isn't much work to fix.

For 0.2.x, support on IE would be nice.

Terminal isn't a fully terminal, and therefor should be named TermBuffer.

The new TermBuffer should trigger Events, when a line has been changed instead of this non-standard model terminal.js is currently using. This also will fix #4.

I've tested the terminal.js through running node-webterminal.

Simple things like editing a file , etc.. all work fine.
If I try to execute a top or htop then the output is garbled.

Maybe worth checking if you can confirm this behaviour?

If we want to make this library easily integration into a web client, I think it would make sense to move the webterminal code into this repo. This is to be as close as possible to the term.js as possible. Maybe create a directory webdist? or jquery?

The other option is to create a separate jquery module repo. but that will only be a hassle to sync with the code.

To iterate over the format and see what modes a certain cell has is pretty inconvenient with the new internal format:

as we currently store the mode changes in the buffer , you'll have to re-execute the full stream every time to understand the current attrs of a cell. Unless I'm not getting it.

The old format had instant, cell , attr access make it easier to iterate over.

At the moment, terminal.js only cares about the backend of a terminal. For the 0.2 milestone, it should support basic render tasks which are currently done in external libraries (e.g. webterminal.js)

This class(es) should support html, ascii, and DOM manipulation targets.

An class hierarchie proposal:

• Renderer: Base class for rendering
  • HtmlRenderer: renders HTML
  • PlainRenderer: like the toString() method in Terminal
  • LiveRenderer: Base class for live-rendering
    • DomRenderer: inherits HtmlRenderer, changes content of a dom element when terminal is changed
    • TtyRenderer: renders to a tty. Can be used for screen-like applications
    • CanvasRenderer: renders to a HTML5 canvas. Not sure, if there's an advantage over DomRenderer other than speed.

A class member proposal:

• Renderer(terminal, options)
  • toString(): returns string representation of current terminal.
• LiveRenderer(terminal, target, options)
  • __insertLine(nbr)_: insert new line before line at index nbr. should return an object containing the view representation of the line.
  • __removeLine(nbr, view)_: remove line at index nbr.
  • __changeLine(nbr, view, startOffset, line)_: change line, starting at startOffset.
  • __changeLed(led1, led2, led3, led4)_: Change LED-Status
  • __clear()_: Clear screen.

Renderer should not rely on external libraries like jQuery or ansi.js.

You can detect the screen resize of a pty using the SigWINCH signal ,
it would be nice if you could pass this event to the terminal

This commit removes the BrowserBuild and introduces Browserify as discussed.
Terminal now inherits from EventEmitter and can emit events.
A simple inject event is emitted and an in browser test for testing event emitted is added.

jedi4ever@02a347d

Please merge #14 first then I can submit a pull request for this.

I don't know if it has to do with recent commits, but when I now do

$ TERM=vt220 (or screen-256-color ...)
$ clear

the screen will not clear, only the cursor will go to the top.
with TERM=vt100 is works.

The line
https://github.com/c3ks/terminal.js/blob/master/lib/output/html.js#L96 barfs on me sometimes with: Uncaught TypeError: Cannot read property 'bg' of undefined

I reproduce it when starting htop, and going right and left with my arrows a few times.
Should attr. be ever empty?

Setting the scrollregion in the codes is done with 1..cols, 1...rows

But the internal buffer format is on 0..cols-1 , 0..rows-1.
Therefore I'm puzzled that it gets initialized to [0,this.height] and not [0,this.height -1]

It is still the scrollregion that makes the vt100 torture test fail. due to the ESC[1,24r code in it.

https://github.com/c3ks/terminal.js/blob/TermBuffer2/lib/term_buffer.js#L67

This was quick and dirty. Make a extra property for title, icon and alternative colors.

We should be able to dynamically change the source of a terminal and add/remove in- and outputs.

f.e. italic needs to be initialized

you may want to cherry-pick this - jedi4ever@0e79b72

On an terminal with 80,24, when I do a write of

\x1b24;1Hline1\nline2

it should hold max 24 lines and it contains 25.

I guess it start with an error in the ScrolLRegion being defined as [0,Height] where this should be [0,height-1] , from there I guess it propogates further into asssumptions of the code with error. Most likely in the scroll function.

I'll await the new TermBufffer2 API to further investigate.

there is an overlap with https://github.com/dtinth/headless-terminal -

do you think you'll be actively maintaining it? or it is more of an archiving of the project you did on github (which is fine for me!) . I'm just trying to understand the best option to take for integrating it.

the only pointer to the MIT license is in the package.json, it makes it easier if we have LICENSE file containing the MIT license.

I'm exploring the use of your library. Thanks for sharing!

In parts of the code eraseChar is called, but it is never defined?
Just wondering if I'm missing something ?

Occasionally this gets called when I run f.i. htop

Hi I'm trying the following scenario.

On the server side I have a terminal that receives the write changes. I figured from the node-terminal that I can use the Termdiff to calculate the difference since the last writes.

The downside of the current terminalDiff is that you could only use it once and then the internal oldBuffer gets reset.

The problem I'm facing is that when new clients connect they need a 'full' resync of the terminal state. I could opt to add a Termdiff.fullDiff to create a kind of 'total'screen state patch.

Another approach could be to keep 2 terminals and make Termdiff a function between (term1,term2).

To get the full state you could:

var backendTerm = new Terminal();
backendTerm.write('some stuff');

var freshTerm = new Terminal() ; 
var diff = freshTerm.diff(backendTerm);

be curious what approach you'd suggest.

lines can be halfsize , double size etc...

The current internal buffer format does not have a way to store it.
This might have an impact on renderers, diff when the internal format needs to change.

So we'd better do it now :)

TermBuffer now supports simple 'inject' events.

The eventsystem should be more advanced and trigger the following events:

• linechange: as soon as a line finished a change, this event should be triggered. terminal.js has some potential to not trigger this event after any character inserted, but for that, some code changes are needed, i.e. inject() can insert more than one character.
• lineinsert: after a line is inserted
• lineremove: after a line is removed
• cursormove: whenever the cursor changes its position, trigger this event. As above, terminal.js can decide if it is useful to trigger or not.
• ledchange: when the state of an LED has changed
• bell: when a bell is triggered
• request: requests attributes from terminal
• resize: when the terminal changed its size (this will be triggered after corresponding linechange, lineinserted and lineremoved events)
• ...

TermWriter should emit the following events:

• finish: a junk of data is finished. Now it is the right time to re-render the view or create a diff.

These commands should be enough to satisfy rendering.

This is one of the most stupid modes ever... Anyway, vim uses them.

TermDiff should be usable

I think it would be useful to have a full square(cols,rows) border around the terminal webelement instead of only the lines that got renderer. It should take terminal(rows,cols) for initial display of a background or something similar

I've noticed that is uses a hash. But for iterating over the lines an array would make more sense. Is there a reason why this done?

To reproduce:

• create file in VI
• enter a bunch of lines (30)
• and then go up
• and scroll beyond the screen.

this results in: (no errors in console in browser)

A new change has been made :
var terminal = new Terminal(target,socket,80, 24);

I think for people using the lib, it will be confusing to specify the socket as a param.
Or at least as the second param

var terminal = new Terminal(target,80,24);
then they may use terminal.writer.write
(which is counterintuitive again , terminal.write should alias this)

if they want to use the live update, they can add it as the 4th param.
var terminal = new Terminal(target,80,24, socket);

And then you may want to link a different output and input there as well.

food for thought.

from the example in the dom_renderer , I can't load it. I suspect terminal.js needs an export as well?

see failed test.

in csi.js ... what happened?

• insertBlanks
• deleteCharacters

5377c59

when I open a vi window , enter some lines and then go back up, it gives me 'unknown escape character g' and display the letter 'g'

ttyrec from the session can be found at https://docs.google.com/file/d/0B4UCodwCv313cmwyQlhLZlVraHM/edit?usp=sharing

when I executed a cat vt100test.txt is break my terminal in a way that my cursor will be on the firstline only and I can't even see new characters appear.

P.S. Maybe if you would explain your debugging workflow a bit? I'm happy to start adding sequences etc.. if they are missing?

This test (commented for now) is failing

jedi4ever@0948bc8

You can see it in action with make torture

Since barf testing was introduced, there were several error messages printed out. get rid of them (old IEs aren't supporting console.log, so these tests will fail on them anyway)

support different types of inputs, e.g.:

• DomInput: Use a Dom-Element for catching KeyPresses and them to the pty
• NodeInput: Use a node.js process to catch stdin, stdout and signals

greedy redraw causes outputs to redraw itself only on completed junks or after a timeout. This should improve the performance of DomOutput dramatically.

This should be implemented in it's own class, so we could use that to improve network performance on slow connections too.

There are a bunch of projects called terminal.js. So, it makes sense to find a new unique name.

suggestions:

• vt.js
• term.js
• jvt
• jsterm
• termlib.js

In Pullrequest #30 were changes made to csi and modes. Backport these to the TermWriter branch

I will like to add a support for big5 encoding support, so can I fork it?

Seem like there is no mention of license in this project.

when the scroll area of htop is scrolled upwards, it only scrolls the two top lines.

Can be reproduced with TERM={screen,vt100,xterm}

At the moment, README.md is a little messy. Clean it up and give the developer a simple starting point to work with the library.

I did an npm install and when I run make coverage it seems to be missing this reporter

right:

wrong:

alt: "Please kill me!"

Don't let Yoshi wanna kill himself. Fix this bug.