| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The text buffer can now shrink, which means we need to be careful to erase
the old location of the cursor. Just clear screen before render each time.
Which means we need to be more efficient with our rendering.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It might be too ambitious for an initial Mu system, and I also want to
watch my novelty budget. I also have great doubts about the ability of
this live-updating postfix system to scale to interesting programs. Conditionals,
loops, multi-line functions, all this requires further work.
Instead, I'm going to recenter around Mu's original goals:
- saying no to most features
- encouraging/teaching testing
- traces as a unifying metaphor
In particular, instead of a live-updating system, the new debug loop will
be:
- generate a trace
- browse the trace
- modify the program
- generate a trace
- ...
The only persistence we'll need here is a way to track what the programmer
has drilled into in the trace. That might have some commonalities with
the old system of expanded words.
|
| |
|
|
| |
Just some temporary files before I blow them away.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Forget about support for quitting for now. Quit by rebooting the computer
or VM.
|
| | |
|
| | |
|
| |
|
|
| |
First bugfix in baremetal/shell. Already it's much easier to debug.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is quite new and speculative. I tried to list out some potential future
tests later when we add 'return'. We'll see how it goes.
|
| | |
|
| |
|
|
| |
Game of Life with a larger grid.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Now there's a neat resonance carrying over all 3 levels of Mu notation.
|
| | |
|
| |
|
|
|
| |
In the process I found a bug in the Mu compiler. Limitations of just asserting
the emitted code but not running it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Bugfix in clear-screen.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Pretty thin; perhaps we should put cursor management in words. But we don't
need every node in the list of words to know which word in the list the
cursor is at.
|
| |
|
|
| |
Include a file for commit 7708.
|
| |
|
|
|
|
|
| |
Fix the jarringness in the previous commit. Gap buffers now always occupy
the same width on screen regardless of where their cursor is. The price:
we sometimes have more whitespace between words. But that is perhaps a
good thing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not everything here is tested, but enough that I'm starting to feel confident.
We see our first divergence with apps/tile. In apps/tile we render everything,
then go back and figure out where to position the cursor. This relies on
some low-level smarts and is also quite klunky and complex.
In baremetal/shell I plan to do something simpler: maintain a tree of objects
where each level knows which sub-object under it has the cursor. Now I
can pass in the cursor object to each object, and if it detects that it
has the cursor it can recursively figure out which sub-object has the cursor.
The bottom-most objects (grapheme stacks) draw the cursor as they render
themselves. Single-pass algorithm, draw the cursor as you render, no low-level
smarts needed.
But there's a divergence. What in apps/tile used to look like this, with
a cursor ␣ at the end of the word 'abc':
abc␣def
..now looks like this:
abc␣ def
..with an extra space.
This could cause some jarring 'dancing' as you move the cursor through a
list of words.
|
| | |
|
| | |
|
| | |
|