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.)
We don't want to do this during app initialization because other forks
might not start out with an editor on screen even if this one does.
We also don't want to perform side-effects like this within
edit.mouse_press.
After using get_rect in edit.draw I grow more confident that this is a
better approach. The only drawback is that edit.up and
edit._up_whole_screen_lines need some extra work to fight the
abstraction of get_rect. But that feels like a net win.
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 :/)
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 :/)
scenario:
start with an empty file, there's one line with a '+' button on it
press the '+' to create a drawing in the top line
press C-z to undo
= before this commit, undo would create a weird intermediate state where there were two lines with '+' on them
scenario:
type something into the first line, press enter to append a second line
press the '+' on the second line to create a drawing
press C-z to undo
= crash
The root cause in both cases: we end up creating 2 undo events starting
from the same before snapshot: one inside the button handler, and a
second on mouse release.
This doesn't affect lines 1 because we had a separate variable called
current_drawing which protected the mouse release handler from
triggering.
scenario:
start with an empty file, there's one line with a '+' button on it
press the '+' to create a drawing in the top line
press C-z to undo
= before this commit, undo would create a weird intermediate state where there were two lines with '+' on them
scenario:
type something into the first line, press enter to append a second line
press the '+' on the second line to create a drawing
press C-z to undo
= crash
The root cause in both cases: we end up creating 2 undo events starting
from the same before snapshot: one inside the button handler, and a
second on mouse release.
This doesn't affect lines 1 because we had a separate variable called
current_drawing which protected the mouse release handler from
triggering.
scenario:
* open a file with a drawing on the first line
* position cursor in the line below
* hit backspace
I _think_ this is the only place where I need to update screen_top
_before_ the scroll check (because screen_top switches mode and has
gotten corrupted).
scenario:
* open a file with a drawing on the first line
* position cursor in the line below
* hit backspace
I _think_ this is the only place where I need to update screen_top
_before_ the scroll check (because screen_top switches mode and has
gotten corrupted).
I think the only situation this can happen is after pressing C-a to
select a file (that doesn't fit on screen). But it's important for
potential forks, e.g. positioning editors on infinite surfaces.
I think the only situation this can happen is after pressing C-a to
select a file (that doesn't fit on screen). But it's important for
potential forks, e.g. positioning editors on infinite surfaces.