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.
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.
When I'm also checking graphemes I assume that spaces can be in other bg
colors. However, if I want to closely check the bg color for a cell with
a space in it (ahem, cursor), I have to check the color in isolation.
No handler yet, just initialization.
Bochs boots up; Qemu gets into a reboot loop.
Unlike the keyboard where I did the minimum necessary for Qemu, here I
am blindly copying something alleged to work on "real hardware." Makes
no difference to the failure modes I'm seeing.
Even in this tiny endeavor I see the abyss open up. Poke bytes at some
sequence of ports, read back bytes from some sequence ports; it's like
sending out prayers.
This was tedious for three reasons beyond the usual one of having to
track and update offsets several time while I debug:
- The Bochs troubles of the previous commit kept polluting my brain
even though they were irrelevant.
- I had to keep some changes locally to allow myself to use Bochs,
which polluted my working directory.
- I had to travel the long way to the realization that I'm not
actually initializing the stack anywhere. BIOS was starting my stack
off at 0x10000, which was promptly clobbered by my second read from
disk.
The good news: while I'm here I grow the interrupt descriptor table. So
I don't have to go through this exercise when I get back to supporting
the mouse.
Oh, stupid mistake in segmented address calculation. Now Qemu's working
again everywhere. Bochs is again broken everywhere. But I think we're
getting closer. I think Bochs's BIOS implementation for reading sectors
has two interacting constraints:
- Can't write to more than 0x10000 bytes past segment register.
- Can't write across segment alignment boundaries.
Qemu only cares about the first.
While baremetal has been working with Qemu, it's been broken with Bochs
since commit 7547, where we started reading more than 63 sectors (1
track) from disk.
Good to know that Bochs simulates native hardware with so much
verisimilitude!
Unfortunately things aren't fixed yet. The current state:
- Qemu - - Bochs -
ex2.hex never switches modes works
ex2.subx never switches modes works
ex2.mu never switches modes fails unit tests
It sucks that Bochs doesn't have strictly superior verisimilitude
compared to Qemu :(
