| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Revert commits 3824, 3850 and 3852. We'll redo them more carefully.
|
| |
|
|
|
|
| |
Bring back commit 3844, albeit in simplified form. I'd forgotten that the
one place where we still need to buffer rendering is when people hold down
up/down arrow keys.
|
| |
|
|
|
| |
Once I start optimizing most events to not repaint everything there's no
need to be smart about queued-up events.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now it's much more apparent why things are slow. You can see each repaint
happening. Already I fixed one performance bug -- in clear-rest-of-screen.
Since this subverts Mu's fake screen there may be bugs.
Another salubrious side effect: I've finally internalized that switching
to raw mode doesn't have to clear the screen. That was just an artifact
of how termbox abstracted operations. Now I can conceive of using termbox
to build a repl as well.
(I was inspired to poke into termbox internals by
http://viewsourcecode.org/snaptoken/kilo and
https://github.com/antirez/linenoise)
|
| | |
|
| | |
|
| |
|
|
|
| |
Manual tests for parse errors because scenarios can't handle assertion
failures yet.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On slow networks sometimes escape sequences were being partially
consumed, causing junk to be added to the editor when you pressed arrow
keys and so on. Now we have a way to wait.
Empirically seems to work if I page-up and then scroll back up using
up-arrow. Before I'd consistently get junk even on my local machine. Now
I no longer do.
If we still see problems I'll increase the wait time and see if the
increase helps. Then we'll know more about this approach.
|
|
|
This bit of code is complex enough now that I'm bothered I can't write
tests for has-more-events?
|