We can have multiple rects corresponding to the same location. But only
one of them has show_cursor enabled. This disambiguates which one we
mean.
With the current rect-based design, it's much harder to get 2 cursors
than I thought.
Before this commit lines that split in the middle of a word were
positioning clicks to the right of the margin _before_ the rightmost
character of the screen line.
Now it's slightly visually confusing that the cursor shows up at start
of next wrapping line. Still seems like an improvement, though.
Until now, clicking at the end of a soft-wrapped line would show the
cursor at both the end of the first screen line and the start of the
second.
However, I just noticed a bug: if the soft-wrapped line is splitting
within the middle of a word, 2 cursors appear on the same line. (All is
well when splitting between words.)
First reaction to a bug: delete the offending feature.
This requires also transplanting the 'show_cursor' field support from
text2.
Now the code is easy to reason about: I always show the cursor at a
single place for any given pos. And the pos I'm showing cursor at is
always the current pos.
But this isn't the end of the story. I do like the feature of showing 2
cursors when straddling screen lines.
There's also a second bug in text2 that has also transplanted here:
clicking to the right of a wrapping screen line actually positions
cursor _before_ the right-most character, not after.
I'm going to try to keep lines2 and text2 sync in this respect as I make
future edits. (text2 will continue to exclusively support 'conceal' and
'draw' fields.)
This might have introduced a bug. I _think_ I've checked for functions
without an `Editor` arg, but one may have slipped past. I don't know how
to be sure. (Not without tests :/)
* It receives a starting location, not always a full line. If it starts
in the middle of a line, I only create rects starting from there (and
stop at end of line at most).
* I stop when I create enough screen lines to get to the bottom. This is
important when the caller is trying to compute the location for a
pixel. If I click below all lines, the caller can just grab the
absolute final char rect and everything works out.
up arrow when going up to same line -> crash
right arrow at end of wrapping line -> nothing happens
down arrow from final screen line of line -> nothing happens
An experiment in collaboration with yumaikas.
There's still one open bug that I know about.
There's also an open question: how to handle screen_top when it's not at start of line.
There are still open questions with that:
- say there's a partial drawing up top. Do we want to support drawing on
it? It would be jarring for it to move right as you click on it. But
might also not be a great experience to only see part of it.
- the current problem with snapping cursor to bottom is that I only want
to include whole screen lines in that particular call to edit.up.
On the other hand, drawings were supporting partial screen lines,
which added a second layer of complexity to it. Now there's at least
only one problem.
- all my basic move operations were always maintaining yoff in drawings.
It's meaningless and ignored in cursor for the most part. But if I
ever copy screen_top from cursor I have to remember to reset yoff. Now
there's one less thing to remember.