| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fix the failing scenario of commit 3944.
|
|
|
|
|
|
|
| |
Reintroduce the failing test of commit 3938. It has two problems:
a) it's failing, and
b) it's not failing the same way as with a real screen.
|
|
|
|
| |
Undo commit 3938 and almost everything after. Let's do this right.
|
|
|
|
|
|
|
|
| |
No, my conclusion in the previous commit was wrong. When you print a
character on the right margin, the cursor coordinates always wrap around
to the left margin on the next row. It's just that if you're at the
bottom of the screen, scrolling gives the impression that the row didn't
change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the bug of commit 3938 is now fixed, I'm still trying to
track down why the failure looked different on the fake screen than on
the real one. Snapshot as I try to track down the difference.
One key lesson is that the approach of commit 3860 -- updating the
cursor before rather than after printing each character -- turns out to
be untenable. A sequence of `print` followed by `cursor-position` needs
to behave the same as the real screen.
But it's still not clear how the real screen. When you get to the end of
a line the cursor position wraps after print to the left margin (column
0) on the next row. When you get to the bottom right the cursor position
wraps to the *bottom left* margin. How the heck does it know to scroll
on the next print, then? Is there some hidden state in the terminal?
|
| |
|
| |
|
|
|
|
|
|
|
| |
Fix an out-of-bounds write to the screen when sandboxes aligned just
right.
Thanks Ella Couch for reporting this issue.
|
| |
|
| |
|
|
|
|
|
|
| |
Bugfix: when you hit `enter`, the cursor-row does not increment in *one*
special situation: when the line wraps and the cursor is right at the
start of one of the wrapped lines.
|
|
|
|
| |
Bugfix: adjust row when hitting ctrl-u on wrapped lines.
|
| |
|
|
|
|
|
| |
Bugfix: ctrl-a leaves things consistent in the presence of wrapped
lines.
|
| |
|
| |
|
|
|
|
| |
Bugfix: up-arrow in combination with wrapped lines.
|
|
|
|
| |
Bugfix: handle wrapped lines when moving to end of line.
|
| |
|
| |
|
|
|
|
| |
Remember that `before-previous-line` deals with wrapped screen lines.
|
|
|
|
| |
Bugfix in ctrl-u.
|
| |
|
|
|
|
| |
Standardize functions to put the main object being modified first.
|
|
|
|
| |
Turns out all I had to do was reset `go-render?` to false.
|
|
|
|
|
|
| |
This change is interesting because I only updated one test to gain confidence
that F4 will never redraw the recipe side. (Most of the changes are to
explicitly render-all before each scenario.)
|
| |
|
| |
|
|
|
|
| |
Fix a keyboard shortcut conflict in commit 3884.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks Juan Crispin Hernandez for the suggestion.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Strange race condition: if I repeatedly press <enter> and <backspace> so
the screen is constantly playing catch up, it will sometimes fail these
assertions when it does eventually catch up. Somehow the cursor ends up
misplaced. Let's just take them out. It's likely some low-level implementation
detail of the terminal.
|
| |
|
|
|
|
| |
Clean up a few superficial things in Caleb's commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Yet another bugfix, this time in just the sandbox/ app:
open sandbox/ with empty lesson/ directory
type 'a'
press backspace
cursor was not moving left
Now fixed.
Turns out the sandbox/ app hadn't been working right since commit 3854.
(Which ironically was a revert but clearly didn't revert enough; the last
truly good commit was 3823, and we're still clawing our way back to the
sunlight.)
The issue in this case was that commit 3853 disabled update-cursor in some
situations when it shouldn't have. To be safe, just always update-cursor
one very event. I should probably reorganize this in edit/ as well, but
it's not necessary for this particular bug.
---
Incidentally, as part of my git bisecting I realized that the bug fixed
in the trace browser as part of commit 3862 was very old:
press '/'
press some key
press ctrl-u to erase
press some key
= out of bounds string access
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To achieve this we have to switch to a model of the screen in termbox that
is closer to the underlying terminal.
Before:
a screen is a grid of characters
writing out of bounds does nothing
After:
a screen is a scrolling raster of characters
writing out of bounds wraps to next line and scrolls if necessary
To move to the new model, it was essential that I migrate my fake screen
at the same time to mimic it. This is why the first attempt (commit 3824)
failed (commit 3858). This is also why this commit can't be split into
smaller pieces.
The fake screen now 'scrolls' by rotating screen lines from top to bottom.
There's still no notion of a scrollback buffer.
The newer model is richer; it permits repl-like apps that upstream termbox
can't do easily. It also permits us to simply use `printf` or `cout` to
write to the screen, and everything mostly works as you would expect. Exceptions:
a) '\n' won't do what you expect. You need to explicitly print both '\n'
and '\r'.
b) backspace won't do what you expect. It only moves the cursor back,
without erasing the previous character. It does not wrap.
Both behaviors exactly mimic my existing terminal's emulation of vt100.
The catch: it's easy to accidentally scroll in apps. Out-of-bounds prints
didn't matter before, but they're bugs now. To help track them down, use
the `save-top-idx`, `assert-no-scroll` pair of helpers.
An important trick is to wrap the cursor before rather after printing
a character. Otherwise we end up scrolling every time we print to the
bottom-right character. This means that the cursor position can be invalid
at the start of a print, and we need to handle that.
In the process we also lose the ability to hide and show the screen. We
have to show the prints happening. Seems apt for a "white-box" platform
like Mu.
|
| |
|
| |
|
|
|
|
|
| |
Bugfix on commit 3853: clear `render-all-on-no-more-events` once you've
actually run the `render-all`.
|
|
|
|
| |
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.
|
|
|
|
|
| |
Bugfix: writes out of bounds used to be skipped, but started clobbering
the screen on commit 3824.
|