| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
It comes up pretty early in the codebase, but hopefully won't come up
in the mu level until we get to higher-order recipes. Potentially
intimidating name, but such prime real estate with no confusing
overloadings in other projects!
|
| | |
|
| |
|
|
|
| |
It should now be easy to do dynamic dispatch, create higher-order
functions, etc.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Key idea: wrap whenever you type at the right margin, don't wait for
line to grow past it. That way you always leave room to acquire the end
of the line, and you never have to worry about wrapping just the cursor
but not the line. Simplifies a lot of logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started fixing scenario editor-inserts-character-at-wrapped-cursor,
but as I work further I notice there's an irreconcilable ambiguity in
the approach of letting the cursor wrap in a non-wrapped line: if a
cursor is at column 0 and the previous line occupies the entire width,
should the next character you insert go before (assuming a wrapped
cursor) or after the newline (assuming you're at the start of the next
line)? No way to distinguish the two cases.
One approach would be to delete the newline and have the cursor replace
it with whatever you type. Then you have to hit a newline again to
separate.
But the simpler way is to simply wrap the moment the line grows to
width-1, always leaving room for the cursor. Yeah, let's switch to that
approach.
|
| |
|
|
| |
Move experimenting with wrapped lines to the right column.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We'll start out with just boxes on the right. Unlike the left with its
dotted boundaries, the boundaries on the right will be solid lines, to
indicate that they are isolated from each other even as they take from
all the recipes on the left.
As students grow more advanced we'll provide some way to 'pop up' the
pre- and post-condition fields inside each sandbox. Those will also have
dotted boundaries with the rest of their sandbox.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
All these commented out prints are begging to turn into an app-level
trace. But we need interpolation and static dispatch for that, so we can
start printing any number of arbitrary types.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Clean up some variable names.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Requires better support for special variable names in scenarios like
'screen' and 'console'.
|
| | |
|
| |
|
|
| |
..when building until layer 41
|
| |
|
|
| |
For starters start making the test fail when building until layer 41.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It was stale from before I added the § sentinel.
|
| | |
|
| |
|
|
|
| |
More bugs about pointing outside text.
Still not done.
|
| |
|
|
|
|
|
|
| |
Time to turn on optimizations, since we aren't recompiling mu all the
time anymore.
But it doesn't help much with the editor. We need to be smarter about
not rendering the whole screen.
|
| |
|
|
|
|
|
|
|
|
| |
It can at most be just after the text of a line. If I click further
right, adjust it so it's at the end. If I click below, adjust it so it's
at the end.
Still not perfect. We aren't testing the value of the before-cursor
pointer, and it's actually still wrong when clicking below all the text
in the editor.
|
| |
|
|
|
|
| |
Another case I'm not writing tests for, after the
hide-screen/show-screen pair. But this case at least will eventually get
tests.
|
| |
|
|
| |
Had to take control of tb_present() after all. Termbox was wise.
|
| |
|
|
|
| |
But it doesn't work, because moving the cursor inside 'render' also
starts displaying it again.
|
| | |
|
| | |
|