When long wrapping lines go past the current page, I find myself
scrolling before I get to the bottom. So let's scroll less, usually from
the start of the bottom-most line, even if it wraps multiple screen
lines.
The challenge with this is to ensure that a long line that fills the
whole page by itself doesn't get you stuck. I take some care to make
sure <pagedown> always makes forward progress.
It's still a bit simple-minded. Most software will keep the first bound
fixed and move the second. Lines currently has the bounds in a queue of
sorts. But I have a test to indicate the behavior that is definitely
desired. We'll see if we need it to get more complex.
couple of more temporary bugs:
find sometimes draws highlighted text in wrong place
esc after C-f sometimes ends up with cursor before screen top
But the known issues are harder.
Mouse stuff is pretty strenuous. For the first time I have to be careful
not to recompute too often. And I ran into a race condition for the
first time where resetting line.y within App.draw meant mouse clicks
were extremely unlikely to see line.y set.
Incredibly inefficient, but I don't yet know how to efficiently encode
undo mutations that can span multiple lines.
There seems to be one bug related to creating new drawings; they're not
spawning events and undoing past drawing creation has some weird
artifacts. Redo seems to consistently work, though.
I seem to often accidentally press C-n twice to go into name mode. Now
doing so overrides the previous temporary mode (name/move/delete point)
without clobbering the real shape-drawing mode.
I often find myself accidentally hovering over some shape or other when
switching modes.
One additional reason to do this: I never included it in the help. So it
hasn't been very high-priority.