Use a circular list to manage buffer

[Tyriar]

Fixes #361

This is a work in progress, I'm putting the PR out now so the changes are easier to view and so I can get early feedback. Initial testing shows this is a lot faster in processing a large ls -lR as well as being responsive and showing the output as it's going (as opposed to locking up).

Remaining tasks:

• BUG: Applications that change middle of buffer screw up everything (eg. git log)
• Make sure vim works
• Ensure that all changes to the list that would trigger a change in ybase and ydisp are handled
• Do thorough manual testing and ensure automated tests pass
• Benchmark against current
• Replace usages of CircularList.splice with CircularList.shiftElements where possible

[Tyriar]

@akalipetis @parisk feel free to give this some early feedback if you have the time.

[parisk]

Awesome. This looks great (code and functionality-wise).

Giving it a quick try works like a charm 👍 . Also running ls -lR feels by far more responsive.

I witnessed only mess-ups with git log / top:

If I scrolled x pages down in git log and then scrolled y pages up (y<x), some weird flashing happened.

👍 let's move this forward. I'd be happy to help wherever needed.

[Tyriar]

I still need to do more verification but I believe the bugs are worked out. There are a few lingering TODOs still to do though. After this change we should then get rid of the majority if not all of the CircularList.splice calls and replace them with a much faster function(s) that sets some element and shifts n elements by 1 index as that seems to be its main purpose (see reverseIndex).

An early comparison shows with an ls -lR ~ on my machine gives the following results:

• master: 43 seconds to finish, browser locked up and showed unresponsive dialog after 30s
• CircularList: 26 seconds to finish, constant text scrolling ✨

[parisk]

@Tyriar a few comments on the TODO list:

Ensure that all changes to the list that would trigger a change in ybase and ydisp are handled

This will be handled in automated tests, right?

Do thorough manual testing [...]

Can you update this with the test cases you have in mind, in order for the rest of us to contribute as well?

Benchmark against current

Should we consider this as ✔︎ done, since we have the ls -lR ~ metric you provided.

[Tyriar]

@parisk

This will be handled in automated tests, right?

If possible, having had jumped into this escape sequence code I have a far better understanding of how it all works. I might follow this one with some refactors and tests, rather than jamming it all into this PR.

Can you update this with the test cases you have in mind, in order for the rest of us to contribute as well?

Ideas right now:

• See if we can expand the automated escape sequence tests that are already present
• Play with git, vim, less, etc. when the buffer is full and not full

Should we consider this as ✔︎ done, since we have the ls -lR ~ metric you provided.

I might see if I can write an automated perf test first, it would be nice to have something a little more solid than a timer on my phone 😄

I was also thinking maybe we could look at adding the PR that syncs #146 to see if we've overcome the issues that made this slow. It would be awesome if time was accurate, both for the end user and for testing purposes. Created #425

[Tyriar]

Automated testing is probably best left for better support within xterm.js. I did some more tests and compared it to gnome-terminal too:

	master	CircularList	gnome-terminal
Print 1..500000	55s	8s	3.5s
ls -lR ~ (524582 files)	68s	29s	6s

Here's the print test: for x in {1..500000}; do echo $x; done

[Tyriar]

This is ready for a full review now.

[parisk]

👍 This looks mostly 👌. Just a couple of comments and we are good to go.

Also did a few manual tests on this and the experience is definitely faster than before.

[parisk]

Can you update the license according to the paradigm set in #388

[Tyriar]

50cfe2b

[parisk]

What is the issue here?

[Tyriar]

It's done just below, it could probably be merged with the one below.