Matt Wynne pointed out that snap.love would crash when a node went off
screen. While debugging it I noticed that selection1 was being set when
it shouldn't be.
Turns out I introduced a bug when I fixed the inscript bug back in June
(commit 9656e13774). One invariant I want to preserve is: selection1
should be unset after a mouse click (press and release without
intervening drag). This invariant was violated in my bugfix back in
June. I was concerned only with selection back then, and I didn't
realize I was breaking the mouse click case (in a fairly subtle way; you
can have selection set, and when it's set identically to the cursor
everything looks the same).
I think there might still be an issue in snap.love after this fix. I
noticed screen_bottom1.pos was nil, and as far as I recall that should
never happen.
All the Text functions assume the cursor is always on a text line. I was
violating that invariant.
* When scrolling up, I start the cursor at the top-most line below the
screen top.
* When scrolling down, I start the cursor at the top-most line below the
screen bottom.
I think it would feel slightly more natural for it to be the
bottom-most line above the screen bottom.
However, the Text functions maintain an invariant that the bottom-most
line in a buffer will be text. There's no such invariant for the
top-most line.
The drawing buttons are now absolutely positioned, which is a horrible
hack. But for just the source editor it seems good enough. The
alternative is to modify magic constants in all the tests :/
Scenario:
* start out with some text on screen
* select some text A, delete
* select some more text B, delete
* press C-z twice to restore A and B
* press C-y twice
Before this commit only the first C-y was having an effect (deleting B).
The second was failing to delete A.
I see a path to at least maintain a single fragment per screen line. But
can we do better? It even seems unnecessary to maintain two copies of
the data, chopped up into lines and screen lines.
It's just uneconomic to maintain given how little I've used it. I have a
bug right now and no time to port the bugfix to all the complexities of
the B side.
I briefly considered tossing out the entire source editor. But I _have_
been using it to browse logs across sessions. The live editor doesn't
quite cover all my use cases just yet.
We now have duplication in the source editor only for:
* syntax highlighting
* hyperlinking [[WikiWords]]
* ability to hide cursor (when showing file browser or Focus is in log browser)
scenario:
press ctrl+f, type in a string
hit down arrow if needed until the screen scrolls
press enter
click with the mouse somewhere
Before this commit the app would crash because cursor was above screen
top.
Scenario: make some edits, select some text, make some more edits. Press
ctrl-z.
Before this commit, undo would stop at the point of selection and
previous edits would become unreachable.
After this commit, both ctrl-z and ctrl-y seem able to span the point of
selection.
I've been running out of ctrl+ shortcuts, and I just remembered my
original idea to keep ctrl+ for drawings/mouse operations and alt+ for
everything else.