2022-07-12 07:03:27 +01:00
|
|
|
-- some constants people might like to tweak
|
|
|
|
Text_color = {r=0, g=0, b=0}
|
|
|
|
Cursor_color = {r=1, g=0, b=0}
|
|
|
|
Highlight_color = {r=0.7, g=0.7, b=0.9} -- selected text
|
|
|
|
|
2022-07-13 02:29:00 +01:00
|
|
|
Margin_top = 15
|
|
|
|
Margin_left = 25
|
|
|
|
Margin_right = 25
|
|
|
|
|
2022-07-12 06:14:59 +01:00
|
|
|
edit = {}
|
|
|
|
|
|
|
|
-- run in both tests and a real run
|
2023-12-29 19:52:28 +00:00
|
|
|
function edit.initialize_state(top, left, right, font, font_height, line_height) -- currently always draws to bottom of screen
|
2022-07-12 22:18:50 +01:00
|
|
|
local result = {
|
2022-08-15 18:31:56 +01:00
|
|
|
lines = {{data=''}}, -- array of strings
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-12 22:18:50 +01:00
|
|
|
-- Lines can be too long to fit on screen, in which case they _wrap_ into
|
|
|
|
-- multiple _screen lines_.
|
2022-07-18 05:05:01 +01:00
|
|
|
|
|
|
|
-- rendering wrapped text lines needs some additional short-lived data per line:
|
|
|
|
-- startpos, the index of data the line starts rendering from, can only be >1 for topmost line on screen
|
2024-06-16 13:20:05 +01:00
|
|
|
-- screen_line_starting_pos: optional array of codepoint indices if it wraps over more than one screen line
|
2022-07-21 00:34:09 +01:00
|
|
|
line_cache = {},
|
2022-07-18 05:05:01 +01:00
|
|
|
|
|
|
|
-- Given wrapping, any potential location for the text cursor can be described in two ways:
|
2022-07-12 22:18:50 +01:00
|
|
|
-- * schema 1: As a combination of line index and position within a line (in utf8 codepoint units)
|
|
|
|
-- * schema 2: As a combination of line index, screen line index within the line, and a position within the screen line.
|
|
|
|
--
|
|
|
|
-- Most of the time we'll only persist positions in schema 1, translating to
|
|
|
|
-- schema 2 when that's convenient.
|
|
|
|
--
|
|
|
|
-- Make sure these coordinates are never aliased, so that changing one causes
|
|
|
|
-- action at a distance.
|
fix a crash involving mouse and drawings
Thanks Alex Schroeder for reporting this crash. The scenario:
* Edit a file like say this repo's Readme.
* The second line is empty and there's a '+' to insert a drawing.
Click on that.
* Resize the window so just the first line of text and the drawing are
visible.
* Close the window.
* Reopen lines.love, it will reopen the same file.
* Click on the left margin to the left of the drawing.
Before this commit these steps yielded the following crash:
Error: bad argument #1 to 'len' (string expected, got nil)
text.lua:626: in function 'pos_at_end_of_screen_line'
edit.lua:298: in function 'mouse_press'
There were two distinct problems here:
1. State.screen_bottom1 is not required to point to a text line, it
could just as well be a drawing. I have been sloppy in handling that.
2. The bug was partially masked (the need to close and reopen the
window) by a second bug: inserting a drawing was not invalidating the
cache I save of starty coordinates for each line. (I've inserted and
deleted starty invalidations a few times in the past, but it looks
like I'd never had one in this particular location edit.draw before.)
How did these issues get missed for years?
- Even though I use lines.love on a daily basis, it turns out I don't
actually create line drawings all that often.
- When I do, I'm still living in files that are mostly text with only
an occasional drawing.
- I keep my windows fairly large.
Between these 3 patterns, the odds of running into a drawing as the
first or bottom-most line on the screen were fairly small. And then I
had to interact with it. I suspect I tend to interact with drawings
after centering them vertically.
---
Bug #1 in particular has some interesting past history.
* Near the start of the project, when I implemented line-wrapping I
started saving screen_bottom, the bottom-most line displayed on
screen. I did this so I could scroll down easily just by assigning
`screen_top = screen_bottom`. (On the other hand, scrolling up still
required some work. I should perhaps get rid of it and just compute
scrolls from scratch each time.)
* Also near the start of the project, I supported selecting text by a
complex state machine spanning keypress, mouse press and mouse
release:
mouse click (press and immediate release) moves cursor
mouse drag (press and much later release) creates selection
shift-click selects from current cursor to click location
shift-movement creates/grows a selection
* On 2023-06-01, inscript reported a bug. Opening a window with just a
little bit of text (lots of unused space in the window), selecting all
the text and then clicking below all the text would crash the editor.
To fix this I added code at the bottom of edit.mouse_press which
computed the final visible line+pos location and used that in the
cursor-move/text-selection state machine. It did this computation
based on.. screen_bottom. But I didn't notice that screen_bottom could
be a drawing (which has no pos). This commit's bug/regression was
created.
* On 2023-09-20, Matt Wynne encountered a crash which got me to realize
I need code at the bottom of edit.mouse_release symmetric to the code
at the bottom of edit.mouse_press. I still didn't notice that
screen_bottom could be a drawing.
So in fixing inscript's bug report, I introduced (at least) 2
regressions, because I either had no idea or quickly forgot that
screen_bottom could point at a drawing.
While I created regressions, the underlying mental bug feels new. I just
never focused on the fact that screen_bottom could point at a drawing.
This past history makes me suspicious of my mouse_press/mouse_release
code. I think I'm going to get rid of screen_bottom entirely as a
concept. I'll still have to be careful though about the remaining
locations and which of them are allowed to point at drawings:
- cursor and selection are not allowed to point at drawings
- screen_top and screen_bottom are allowed to point at drawings
I sometimes copy between these 4 location variables. Auditing shows no
gaps where cursor could ever end up pointing at a drawing. It's just
when I started using screen_bottom for a whole new purpose (in
the mouse_press/release state machine) that I went wrong.
I should also try getting rid of starty entirely. Is it _really_ needed
for a responsive editor? I think I introduced it back when I didn't know
what I was doing with LÖVE and was profligately creating text objects
willy-nilly just to compute widths.
Getting rid of these two fairly global bits of mutable state will
hopefully make lines much more robust when the next person tries it out
in 6 months :-/ X-(
Thanks everyone for the conversation around this bug:
https://merveilles.town/@akkartik/112567862542495637
---
Bug #2 has some complexity as well, and might lead to some follow-on
cleanup.
When I click on the button to insert a new drawing, the mouse_release
hook triggers and moves the cursor below the new drawing. This is
desirable, but I'd never noticed this happy accident. It stops working
when I invalidate starty for all lines (which gets recomputed and cached
for all visible lines on every frame).
Fixing this caused a couple of unit tests start crashing for 2 reasons
that required their own minor fixes:
- My emulated mouse press and release didn't have an intervening
frame and so mouse_release no longer receives starty. Now I've added
a call to edit.draw() between press and release.
This might actually bite someone for real someday, if they're
running on a slow computer or something like that. I've tried to
click really fast but I can't seem to put mouse_press and release in
the same frame (assuming 30 frames per second)
- My tests' window dimensions often violate my constraint that the
screen always have one line of text for showing the cursor. They're
unrealistically small or have a really wide aspect ratio (width 2x
of height). I suspect lines.love will itself crash in those
situations, but hopefully they're unrealistic. Hmm, I wonder what
would happen if someone maximized in a 16:9 screen, that's almost
2x.. Anyways, I've cleaned a couple of tests up, but might need to
fix up others at some point. I'd have to rejigger all my brittle
line-wrapping tests if I modify the screen width :-/ X-(
2024-06-09 21:17:55 +01:00
|
|
|
--
|
|
|
|
-- On lines that are drawings, pos will be nil.
|
2022-07-12 22:18:50 +01:00
|
|
|
screen_top1 = {line=1, pos=1}, -- position of start of screen line at top of screen
|
fix a crash involving mouse and drawings
Thanks Alex Schroeder for reporting this crash. The scenario:
* Edit a file like say this repo's Readme.
* The second line is empty and there's a '+' to insert a drawing.
Click on that.
* Resize the window so just the first line of text and the drawing are
visible.
* Close the window.
* Reopen lines.love, it will reopen the same file.
* Click on the left margin to the left of the drawing.
Before this commit these steps yielded the following crash:
Error: bad argument #1 to 'len' (string expected, got nil)
text.lua:626: in function 'pos_at_end_of_screen_line'
edit.lua:298: in function 'mouse_press'
There were two distinct problems here:
1. State.screen_bottom1 is not required to point to a text line, it
could just as well be a drawing. I have been sloppy in handling that.
2. The bug was partially masked (the need to close and reopen the
window) by a second bug: inserting a drawing was not invalidating the
cache I save of starty coordinates for each line. (I've inserted and
deleted starty invalidations a few times in the past, but it looks
like I'd never had one in this particular location edit.draw before.)
How did these issues get missed for years?
- Even though I use lines.love on a daily basis, it turns out I don't
actually create line drawings all that often.
- When I do, I'm still living in files that are mostly text with only
an occasional drawing.
- I keep my windows fairly large.
Between these 3 patterns, the odds of running into a drawing as the
first or bottom-most line on the screen were fairly small. And then I
had to interact with it. I suspect I tend to interact with drawings
after centering them vertically.
---
Bug #1 in particular has some interesting past history.
* Near the start of the project, when I implemented line-wrapping I
started saving screen_bottom, the bottom-most line displayed on
screen. I did this so I could scroll down easily just by assigning
`screen_top = screen_bottom`. (On the other hand, scrolling up still
required some work. I should perhaps get rid of it and just compute
scrolls from scratch each time.)
* Also near the start of the project, I supported selecting text by a
complex state machine spanning keypress, mouse press and mouse
release:
mouse click (press and immediate release) moves cursor
mouse drag (press and much later release) creates selection
shift-click selects from current cursor to click location
shift-movement creates/grows a selection
* On 2023-06-01, inscript reported a bug. Opening a window with just a
little bit of text (lots of unused space in the window), selecting all
the text and then clicking below all the text would crash the editor.
To fix this I added code at the bottom of edit.mouse_press which
computed the final visible line+pos location and used that in the
cursor-move/text-selection state machine. It did this computation
based on.. screen_bottom. But I didn't notice that screen_bottom could
be a drawing (which has no pos). This commit's bug/regression was
created.
* On 2023-09-20, Matt Wynne encountered a crash which got me to realize
I need code at the bottom of edit.mouse_release symmetric to the code
at the bottom of edit.mouse_press. I still didn't notice that
screen_bottom could be a drawing.
So in fixing inscript's bug report, I introduced (at least) 2
regressions, because I either had no idea or quickly forgot that
screen_bottom could point at a drawing.
While I created regressions, the underlying mental bug feels new. I just
never focused on the fact that screen_bottom could point at a drawing.
This past history makes me suspicious of my mouse_press/mouse_release
code. I think I'm going to get rid of screen_bottom entirely as a
concept. I'll still have to be careful though about the remaining
locations and which of them are allowed to point at drawings:
- cursor and selection are not allowed to point at drawings
- screen_top and screen_bottom are allowed to point at drawings
I sometimes copy between these 4 location variables. Auditing shows no
gaps where cursor could ever end up pointing at a drawing. It's just
when I started using screen_bottom for a whole new purpose (in
the mouse_press/release state machine) that I went wrong.
I should also try getting rid of starty entirely. Is it _really_ needed
for a responsive editor? I think I introduced it back when I didn't know
what I was doing with LÖVE and was profligately creating text objects
willy-nilly just to compute widths.
Getting rid of these two fairly global bits of mutable state will
hopefully make lines much more robust when the next person tries it out
in 6 months :-/ X-(
Thanks everyone for the conversation around this bug:
https://merveilles.town/@akkartik/112567862542495637
---
Bug #2 has some complexity as well, and might lead to some follow-on
cleanup.
When I click on the button to insert a new drawing, the mouse_release
hook triggers and moves the cursor below the new drawing. This is
desirable, but I'd never noticed this happy accident. It stops working
when I invalidate starty for all lines (which gets recomputed and cached
for all visible lines on every frame).
Fixing this caused a couple of unit tests start crashing for 2 reasons
that required their own minor fixes:
- My emulated mouse press and release didn't have an intervening
frame and so mouse_release no longer receives starty. Now I've added
a call to edit.draw() between press and release.
This might actually bite someone for real someday, if they're
running on a slow computer or something like that. I've tried to
click really fast but I can't seem to put mouse_press and release in
the same frame (assuming 30 frames per second)
- My tests' window dimensions often violate my constraint that the
screen always have one line of text for showing the cursor. They're
unrealistically small or have a really wide aspect ratio (width 2x
of height). I suspect lines.love will itself crash in those
situations, but hopefully they're unrealistic. Hmm, I wonder what
would happen if someone maximized in a 16:9 screen, that's almost
2x.. Anyways, I've cleaned a couple of tests up, but might need to
fix up others at some point. I'd have to rejigger all my brittle
line-wrapping tests if I modify the screen width :-/ X-(
2024-06-09 21:17:55 +01:00
|
|
|
cursor1 = {line=1, pos=1}, -- position of cursor; must be on a text line
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-12 22:18:50 +01:00
|
|
|
selection1 = {},
|
|
|
|
-- some extra state to compute selection between mouse press and release
|
|
|
|
old_cursor1 = nil,
|
|
|
|
old_selection1 = nil,
|
|
|
|
mousepress_shift = nil,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-12 22:18:50 +01:00
|
|
|
-- cursor coordinates in pixels
|
|
|
|
cursor_x = 0,
|
|
|
|
cursor_y = 0,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2023-12-29 19:18:41 +00:00
|
|
|
font = font,
|
2022-07-16 06:12:25 +01:00
|
|
|
font_height = font_height,
|
|
|
|
line_height = line_height,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-13 02:29:00 +01:00
|
|
|
top = top,
|
2022-12-24 00:57:04 +00:00
|
|
|
left = math.floor(left),
|
|
|
|
right = math.floor(right),
|
2022-07-13 02:29:00 +01:00
|
|
|
width = right-left,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2023-03-19 06:12:50 +00:00
|
|
|
filename = love.filesystem.getSourceBaseDirectory()..'/lines.txt', -- '/' should work even on Windows
|
2022-07-12 22:18:50 +01:00
|
|
|
next_save = nil,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-12 22:18:50 +01:00
|
|
|
-- undo
|
|
|
|
history = {},
|
|
|
|
next_history = 1,
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2022-07-12 22:18:50 +01:00
|
|
|
-- search
|
|
|
|
search_term = nil,
|
|
|
|
search_backup = nil, -- stuff to restore when cancelling search
|
|
|
|
}
|
|
|
|
return result
|
2023-12-29 19:18:41 +00:00
|
|
|
end -- edit.initialize_state
|
2022-07-12 06:14:59 +01:00
|
|
|
|
2023-03-17 16:36:38 +00:00
|
|
|
function edit.check_locs(State)
|
|
|
|
-- if State is inconsistent (i.e. file changed by some other program),
|
|
|
|
-- throw away all cursor state entirely
|
|
|
|
if edit.invalid1(State, State.screen_top1)
|
2023-06-08 09:02:54 +01:00
|
|
|
or edit.invalid_cursor1(State)
|
2023-03-17 16:36:38 +00:00
|
|
|
or not Text.le1(State.screen_top1, State.cursor1) then
|
|
|
|
State.screen_top1 = {line=1, pos=1}
|
2023-03-17 18:02:10 +00:00
|
|
|
State.cursor1 = {line=1, pos=1}
|
2023-03-17 16:36:38 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
function edit.invalid1(State, loc1)
|
2023-03-26 15:19:27 +01:00
|
|
|
if loc1.line > #State.lines then return true end
|
|
|
|
local l = State.lines[loc1.line]
|
|
|
|
if l.mode ~= 'text' then return false end -- pos is irrelevant to validity for a drawing line
|
|
|
|
return loc1.pos > #State.lines[loc1.line].data
|
2023-03-17 16:36:38 +00:00
|
|
|
end
|
|
|
|
|
2023-06-08 09:02:54 +01:00
|
|
|
-- cursor loc in particular differs from other locs in one way:
|
|
|
|
-- pos might occur just after end of line
|
|
|
|
function edit.invalid_cursor1(State)
|
|
|
|
local cursor1 = State.cursor1
|
|
|
|
if cursor1.line > #State.lines then return true end
|
|
|
|
local l = State.lines[cursor1.line]
|
|
|
|
if l.mode ~= 'text' then return false end -- pos is irrelevant to validity for a drawing line
|
|
|
|
return cursor1.pos > #State.lines[cursor1.line].data + 1
|
|
|
|
end
|
|
|
|
|
2022-07-12 23:18:45 +01:00
|
|
|
function edit.draw(State)
|
2023-12-29 19:18:41 +00:00
|
|
|
love.graphics.setFont(State.font)
|
2022-07-12 07:03:27 +01:00
|
|
|
App.color(Text_color)
|
2023-11-18 19:30:57 +00:00
|
|
|
assert(#State.lines == #State.line_cache, ('line_cache is out of date; %d elements when it should be %d'):format(#State.line_cache, #State.lines))
|
|
|
|
assert(Text.le1(State.screen_top1, State.cursor1), ('screen_top (line=%d,pos=%d) is below cursor (line=%d,pos=%d)'):format(State.screen_top1.line, State.screen_top1.pos, State.cursor1.line, State.cursor1.pos))
|
2022-08-17 17:36:17 +01:00
|
|
|
State.cursor_x = nil
|
|
|
|
State.cursor_y = nil
|
2022-07-13 02:29:00 +01:00
|
|
|
local y = State.top
|
2022-07-12 06:14:59 +01:00
|
|
|
--? print('== draw')
|
2022-07-12 23:18:45 +01:00
|
|
|
for line_index = State.screen_top1.line,#State.lines do
|
|
|
|
local line = State.lines[line_index]
|
2022-07-12 06:14:59 +01:00
|
|
|
--? print('draw:', y, line_index, line)
|
2022-07-12 23:18:45 +01:00
|
|
|
if y + State.line_height > App.screen.height then break end
|
2022-08-14 17:17:53 +01:00
|
|
|
--? print('text.draw', y, line_index)
|
|
|
|
local startpos = 1
|
|
|
|
if line_index == State.screen_top1.line then
|
|
|
|
startpos = State.screen_top1.pos
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2024-06-11 20:13:18 +01:00
|
|
|
y = Text.draw(State, line_index, y, startpos)
|
2022-08-14 17:17:53 +01:00
|
|
|
--? print('=> y', y)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.search_term then
|
2022-07-13 00:08:24 +01:00
|
|
|
Text.draw_search_bar(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-07-12 23:18:45 +01:00
|
|
|
function edit.update(State, dt)
|
2022-11-04 04:02:31 +00:00
|
|
|
if State.next_save and State.next_save < Current_time then
|
2022-07-26 03:56:39 +01:00
|
|
|
save_to_disk(State)
|
2022-07-12 23:18:45 +01:00
|
|
|
State.next_save = nil
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-07-13 00:30:41 +01:00
|
|
|
function schedule_save(State)
|
|
|
|
if State.next_save == nil then
|
2022-11-04 04:02:31 +00:00
|
|
|
State.next_save = Current_time + 3 -- short enough that you're likely to still remember what you did
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-07-12 23:18:45 +01:00
|
|
|
function edit.quit(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
-- make sure to save before quitting
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.next_save then
|
2022-07-26 03:56:39 +01:00
|
|
|
save_to_disk(State)
|
2023-01-28 18:21:34 +00:00
|
|
|
-- give some time for the OS to flush everything to disk
|
|
|
|
love.timer.sleep(0.1)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-12-24 03:26:05 +00:00
|
|
|
function edit.mouse_press(State, x,y, mouse_button)
|
2024-02-17 05:12:02 +00:00
|
|
|
love.keyboard.setTextInput(true) -- bring up keyboard on touch screen
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.search_term then return end
|
2023-12-02 05:52:10 +00:00
|
|
|
State.mouse_down = mouse_button
|
2023-06-04 20:20:24 +01:00
|
|
|
--? print_and_log(('edit.mouse_press: cursor at %d,%d'):format(State.cursor1.line, State.cursor1.pos))
|
2023-06-03 18:36:05 +01:00
|
|
|
if y < State.top then
|
|
|
|
State.old_cursor1 = State.cursor1
|
|
|
|
State.old_selection1 = State.selection1
|
|
|
|
State.mousepress_shift = App.shift_down()
|
|
|
|
State.selection1 = {
|
2023-06-03 18:43:20 +01:00
|
|
|
line=State.screen_top1.line,
|
|
|
|
pos=State.screen_top1.pos,
|
2023-06-03 18:36:05 +01:00
|
|
|
}
|
|
|
|
return
|
|
|
|
end
|
|
|
|
|
2022-07-12 23:18:45 +01:00
|
|
|
for line_index,line in ipairs(State.lines) do
|
2022-08-14 17:17:53 +01:00
|
|
|
if Text.in_line(State, line_index, x,y) then
|
|
|
|
-- delicate dance between cursor, selection and old cursor/selection
|
|
|
|
-- scenarios:
|
|
|
|
-- regular press+release: sets cursor, clears selection
|
|
|
|
-- shift press+release:
|
|
|
|
-- sets selection to old cursor if not set otherwise leaves it untouched
|
|
|
|
-- sets cursor
|
|
|
|
-- press and hold to start a selection: sets selection on press, cursor on release
|
|
|
|
-- press and hold, then press shift: ignore shift
|
2023-06-04 23:11:24 +01:00
|
|
|
-- i.e. mouse_release should never look at shift state
|
|
|
|
--? print_and_log(('edit.mouse_press: in line %d'):format(line_index))
|
2022-08-14 17:17:53 +01:00
|
|
|
State.old_cursor1 = State.cursor1
|
|
|
|
State.old_selection1 = State.selection1
|
|
|
|
State.mousepress_shift = App.shift_down()
|
|
|
|
State.selection1 = {
|
|
|
|
line=line_index,
|
|
|
|
pos=Text.to_pos_on_line(State, line_index, x, y),
|
|
|
|
}
|
2023-06-04 23:11:24 +01:00
|
|
|
return
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
2023-06-04 20:20:24 +01:00
|
|
|
|
2023-09-20 21:39:29 +01:00
|
|
|
-- still here? mouse press is below all screen lines
|
2023-06-04 20:20:24 +01:00
|
|
|
State.old_cursor1 = State.cursor1
|
|
|
|
State.old_selection1 = State.selection1
|
|
|
|
State.mousepress_shift = App.shift_down()
|
fix a crash involving mouse and drawings
Thanks Alex Schroeder for reporting this crash. The scenario:
* Edit a file like say this repo's Readme.
* The second line is empty and there's a '+' to insert a drawing.
Click on that.
* Resize the window so just the first line of text and the drawing are
visible.
* Close the window.
* Reopen lines.love, it will reopen the same file.
* Click on the left margin to the left of the drawing.
Before this commit these steps yielded the following crash:
Error: bad argument #1 to 'len' (string expected, got nil)
text.lua:626: in function 'pos_at_end_of_screen_line'
edit.lua:298: in function 'mouse_press'
There were two distinct problems here:
1. State.screen_bottom1 is not required to point to a text line, it
could just as well be a drawing. I have been sloppy in handling that.
2. The bug was partially masked (the need to close and reopen the
window) by a second bug: inserting a drawing was not invalidating the
cache I save of starty coordinates for each line. (I've inserted and
deleted starty invalidations a few times in the past, but it looks
like I'd never had one in this particular location edit.draw before.)
How did these issues get missed for years?
- Even though I use lines.love on a daily basis, it turns out I don't
actually create line drawings all that often.
- When I do, I'm still living in files that are mostly text with only
an occasional drawing.
- I keep my windows fairly large.
Between these 3 patterns, the odds of running into a drawing as the
first or bottom-most line on the screen were fairly small. And then I
had to interact with it. I suspect I tend to interact with drawings
after centering them vertically.
---
Bug #1 in particular has some interesting past history.
* Near the start of the project, when I implemented line-wrapping I
started saving screen_bottom, the bottom-most line displayed on
screen. I did this so I could scroll down easily just by assigning
`screen_top = screen_bottom`. (On the other hand, scrolling up still
required some work. I should perhaps get rid of it and just compute
scrolls from scratch each time.)
* Also near the start of the project, I supported selecting text by a
complex state machine spanning keypress, mouse press and mouse
release:
mouse click (press and immediate release) moves cursor
mouse drag (press and much later release) creates selection
shift-click selects from current cursor to click location
shift-movement creates/grows a selection
* On 2023-06-01, inscript reported a bug. Opening a window with just a
little bit of text (lots of unused space in the window), selecting all
the text and then clicking below all the text would crash the editor.
To fix this I added code at the bottom of edit.mouse_press which
computed the final visible line+pos location and used that in the
cursor-move/text-selection state machine. It did this computation
based on.. screen_bottom. But I didn't notice that screen_bottom could
be a drawing (which has no pos). This commit's bug/regression was
created.
* On 2023-09-20, Matt Wynne encountered a crash which got me to realize
I need code at the bottom of edit.mouse_release symmetric to the code
at the bottom of edit.mouse_press. I still didn't notice that
screen_bottom could be a drawing.
So in fixing inscript's bug report, I introduced (at least) 2
regressions, because I either had no idea or quickly forgot that
screen_bottom could point at a drawing.
While I created regressions, the underlying mental bug feels new. I just
never focused on the fact that screen_bottom could point at a drawing.
This past history makes me suspicious of my mouse_press/mouse_release
code. I think I'm going to get rid of screen_bottom entirely as a
concept. I'll still have to be careful though about the remaining
locations and which of them are allowed to point at drawings:
- cursor and selection are not allowed to point at drawings
- screen_top and screen_bottom are allowed to point at drawings
I sometimes copy between these 4 location variables. Auditing shows no
gaps where cursor could ever end up pointing at a drawing. It's just
when I started using screen_bottom for a whole new purpose (in
the mouse_press/release state machine) that I went wrong.
I should also try getting rid of starty entirely. Is it _really_ needed
for a responsive editor? I think I introduced it back when I didn't know
what I was doing with LÖVE and was profligately creating text objects
willy-nilly just to compute widths.
Getting rid of these two fairly global bits of mutable state will
hopefully make lines much more robust when the next person tries it out
in 6 months :-/ X-(
Thanks everyone for the conversation around this bug:
https://merveilles.town/@akkartik/112567862542495637
---
Bug #2 has some complexity as well, and might lead to some follow-on
cleanup.
When I click on the button to insert a new drawing, the mouse_release
hook triggers and moves the cursor below the new drawing. This is
desirable, but I'd never noticed this happy accident. It stops working
when I invalidate starty for all lines (which gets recomputed and cached
for all visible lines on every frame).
Fixing this caused a couple of unit tests start crashing for 2 reasons
that required their own minor fixes:
- My emulated mouse press and release didn't have an intervening
frame and so mouse_release no longer receives starty. Now I've added
a call to edit.draw() between press and release.
This might actually bite someone for real someday, if they're
running on a slow computer or something like that. I've tried to
click really fast but I can't seem to put mouse_press and release in
the same frame (assuming 30 frames per second)
- My tests' window dimensions often violate my constraint that the
screen always have one line of text for showing the cursor. They're
unrealistically small or have a really wide aspect ratio (width 2x
of height). I suspect lines.love will itself crash in those
situations, but hopefully they're unrealistic. Hmm, I wonder what
would happen if someone maximized in a 16:9 screen, that's almost
2x.. Anyways, I've cleaned a couple of tests up, but might need to
fix up others at some point. I'd have to rejigger all my brittle
line-wrapping tests if I modify the screen width :-/ X-(
2024-06-09 21:17:55 +01:00
|
|
|
State.selection1 = Text.final_text_loc_on_screen(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
function edit.mouse_release(State, x,y, mouse_button)
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.search_term then return end
|
2023-06-04 23:11:24 +01:00
|
|
|
--? print_and_log(('edit.mouse_release(%d,%d): cursor at %d,%d'):format(x,y, State.cursor1.line, State.cursor1.pos))
|
2023-12-02 05:52:10 +00:00
|
|
|
State.mouse_down = nil
|
2023-09-20 22:32:01 +01:00
|
|
|
if y < State.top then
|
2024-06-28 06:15:12 +01:00
|
|
|
State.cursor1 = deepcopy(State.screen_top1)
|
2023-09-20 22:32:01 +01:00
|
|
|
edit.clean_up_mouse_press(State)
|
|
|
|
return
|
|
|
|
end
|
2022-08-14 17:17:53 +01:00
|
|
|
for line_index,line in ipairs(State.lines) do
|
|
|
|
if Text.in_line(State, line_index, x,y) then
|
2023-06-04 23:11:24 +01:00
|
|
|
--? print_and_log(('edit.mouse_release: in line %d'):format(line_index))
|
2022-08-14 17:17:53 +01:00
|
|
|
State.cursor1 = {
|
|
|
|
line=line_index,
|
|
|
|
pos=Text.to_pos_on_line(State, line_index, x, y),
|
|
|
|
}
|
2023-06-04 23:11:24 +01:00
|
|
|
--? print_and_log(('edit.mouse_release: cursor now %d,%d'):format(State.cursor1.line, State.cursor1.pos))
|
2023-09-20 21:39:29 +01:00
|
|
|
edit.clean_up_mouse_press(State)
|
|
|
|
return
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
2023-09-20 22:32:01 +01:00
|
|
|
|
|
|
|
-- still here? mouse release is below all screen lines
|
2024-06-11 20:13:18 +01:00
|
|
|
State.cursor1 = Text.final_text_loc_on_screen(State)
|
2023-09-20 22:32:01 +01:00
|
|
|
edit.clean_up_mouse_press(State)
|
2023-06-04 23:11:24 +01:00
|
|
|
--? print_and_log(('edit.mouse_release: finally selection %s,%s cursor %d,%d'):format(tostring(State.selection1.line), tostring(State.selection1.pos), State.cursor1.line, State.cursor1.pos))
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
|
2023-09-20 21:39:29 +01:00
|
|
|
function edit.clean_up_mouse_press(State)
|
|
|
|
if State.mousepress_shift then
|
|
|
|
if State.old_selection1.line == nil then
|
|
|
|
State.selection1 = State.old_cursor1
|
|
|
|
else
|
|
|
|
State.selection1 = State.old_selection1
|
|
|
|
end
|
|
|
|
end
|
|
|
|
State.old_cursor1, State.old_selection1, State.mousepress_shift = nil
|
|
|
|
if eq(State.cursor1, State.selection1) then
|
|
|
|
State.selection1 = {}
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-03-24 04:00:09 +00:00
|
|
|
function edit.mouse_wheel_move(State, dx,dy)
|
|
|
|
if dy > 0 then
|
2024-06-23 18:53:19 +01:00
|
|
|
State.cursor1 = deepcopy(State.screen_top1)
|
2023-03-24 04:00:09 +00:00
|
|
|
for i=1,math.floor(dy) do
|
|
|
|
Text.up(State)
|
|
|
|
end
|
2023-03-24 04:38:33 +00:00
|
|
|
elseif dy < 0 then
|
2024-06-11 14:58:07 +01:00
|
|
|
State.cursor1 = Text.screen_bottom1(State)
|
2023-03-24 04:00:09 +00:00
|
|
|
for i=1,math.floor(-dy) do
|
|
|
|
Text.down(State)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
function edit.text_input(State, t)
|
2023-03-26 17:36:41 +01:00
|
|
|
--? print('text input', t)
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.search_term then
|
|
|
|
State.search_term = State.search_term..t
|
2022-07-13 01:02:53 +01:00
|
|
|
Text.search_next(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
else
|
2022-12-24 03:47:10 +00:00
|
|
|
Text.text_input(State, t)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-13 00:30:41 +01:00
|
|
|
schedule_save(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
function edit.keychord_press(State, chord, key)
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.selection1.line and
|
2022-07-12 06:14:59 +01:00
|
|
|
-- printable character created using shift key => delete selection
|
|
|
|
-- (we're not creating any ctrl-shift- or alt-shift- combinations using regular/printable keys)
|
|
|
|
(not App.shift_down() or utf8.len(key) == 1) and
|
2024-02-04 17:31:36 +00:00
|
|
|
chord ~= 'C-a' and chord ~= 'C-c' and chord ~= 'C-x' and chord ~= 'backspace' and chord ~= 'delete' and chord ~= 'C-z' and chord ~= 'C-y' and not App.is_cursor_movement(key) then
|
2024-09-01 02:59:23 +01:00
|
|
|
Text.delete_selection_and_record_undo_event(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-12 23:18:45 +01:00
|
|
|
if State.search_term then
|
2022-07-12 06:14:59 +01:00
|
|
|
if chord == 'escape' then
|
2022-07-12 23:18:45 +01:00
|
|
|
State.search_term = nil
|
|
|
|
State.cursor1 = State.search_backup.cursor
|
|
|
|
State.screen_top1 = State.search_backup.screen_top
|
|
|
|
State.search_backup = nil
|
2024-07-08 08:26:54 +01:00
|
|
|
Text.redraw_all(State) -- if we're scrolling, reclaim all line caches to avoid memory leaks
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'return' then
|
2022-07-12 23:18:45 +01:00
|
|
|
State.search_term = nil
|
|
|
|
State.search_backup = nil
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'backspace' then
|
2022-07-12 23:18:45 +01:00
|
|
|
local len = utf8.len(State.search_term)
|
|
|
|
local byte_offset = Text.offset(State.search_term, len)
|
|
|
|
State.search_term = string.sub(State.search_term, 1, byte_offset-1)
|
2024-06-23 18:36:53 +01:00
|
|
|
State.cursor = deepcopy(State.search_backup.cursor)
|
|
|
|
State.screen_top = deepcopy(State.search_backup.screen_top)
|
|
|
|
Text.search_next(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'down' then
|
2022-07-12 23:18:45 +01:00
|
|
|
State.cursor1.pos = State.cursor1.pos+1
|
2022-07-13 01:02:53 +01:00
|
|
|
Text.search_next(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'up' then
|
2022-07-13 01:02:53 +01:00
|
|
|
Text.search_previous(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
return
|
|
|
|
elseif chord == 'C-f' then
|
2022-07-12 23:18:45 +01:00
|
|
|
State.search_term = ''
|
2022-09-05 19:28:03 +01:00
|
|
|
State.search_backup = {
|
|
|
|
cursor={line=State.cursor1.line, pos=State.cursor1.pos},
|
|
|
|
screen_top={line=State.screen_top1.line, pos=State.screen_top1.pos},
|
|
|
|
}
|
2022-08-18 18:09:20 +01:00
|
|
|
-- zoom
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C-=' then
|
2022-07-16 06:15:07 +01:00
|
|
|
edit.update_font_settings(State, State.font_height+2)
|
2022-07-13 01:24:01 +01:00
|
|
|
Text.redraw_all(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C--' then
|
2023-03-18 02:58:49 +00:00
|
|
|
if State.font_height > 2 then
|
|
|
|
edit.update_font_settings(State, State.font_height-2)
|
|
|
|
Text.redraw_all(State)
|
|
|
|
end
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C-0' then
|
2022-07-16 06:15:07 +01:00
|
|
|
edit.update_font_settings(State, 20)
|
2022-07-13 01:24:01 +01:00
|
|
|
Text.redraw_all(State)
|
2022-08-18 18:09:20 +01:00
|
|
|
-- undo
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C-z' then
|
2022-07-13 00:55:32 +01:00
|
|
|
local event = undo_event(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
if event then
|
|
|
|
local src = event.before
|
2022-07-12 23:18:45 +01:00
|
|
|
State.screen_top1 = deepcopy(src.screen_top)
|
|
|
|
State.cursor1 = deepcopy(src.cursor)
|
|
|
|
State.selection1 = deepcopy(src.selection)
|
|
|
|
patch(State.lines, event.after, event.before)
|
2024-07-08 08:26:54 +01:00
|
|
|
Text.redraw_all(State) -- if we're scrolling, reclaim all line caches to avoid memory leaks
|
2022-07-13 00:30:41 +01:00
|
|
|
schedule_save(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
elseif chord == 'C-y' then
|
2022-07-13 00:55:32 +01:00
|
|
|
local event = redo_event(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
if event then
|
|
|
|
local src = event.after
|
2022-07-12 23:18:45 +01:00
|
|
|
State.screen_top1 = deepcopy(src.screen_top)
|
|
|
|
State.cursor1 = deepcopy(src.cursor)
|
|
|
|
State.selection1 = deepcopy(src.selection)
|
|
|
|
patch(State.lines, event.before, event.after)
|
2024-07-08 08:26:54 +01:00
|
|
|
Text.redraw_all(State) -- if we're scrolling, reclaim all line caches to avoid memory leaks
|
2022-07-13 00:30:41 +01:00
|
|
|
schedule_save(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
-- clipboard
|
2022-11-19 08:11:39 +00:00
|
|
|
elseif chord == 'C-a' then
|
|
|
|
State.selection1 = {line=1, pos=1}
|
|
|
|
State.cursor1 = {line=#State.lines, pos=utf8.len(State.lines[#State.lines].data)+1}
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C-c' then
|
2022-07-13 00:43:23 +01:00
|
|
|
local s = Text.selection(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
if s then
|
2023-08-30 14:43:01 +01:00
|
|
|
App.set_clipboard(s)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
elseif chord == 'C-x' then
|
2024-09-01 02:59:23 +01:00
|
|
|
local s = Text.cut_selection_and_record_undo_event(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
if s then
|
2023-08-30 14:43:01 +01:00
|
|
|
App.set_clipboard(s)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-13 00:30:41 +01:00
|
|
|
schedule_save(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
elseif chord == 'C-v' then
|
|
|
|
-- We don't have a good sense of when to scroll, so we'll be conservative
|
|
|
|
-- and sometimes scroll when we didn't quite need to.
|
2022-07-12 23:18:45 +01:00
|
|
|
local before_line = State.cursor1.line
|
2022-07-13 00:55:32 +01:00
|
|
|
local before = snapshot(State, before_line)
|
2023-08-30 14:43:01 +01:00
|
|
|
local clipboard_data = App.get_clipboard()
|
2022-07-12 06:14:59 +01:00
|
|
|
for _,code in utf8.codes(clipboard_data) do
|
|
|
|
local c = utf8.char(code)
|
|
|
|
if c == '\n' then
|
2022-07-13 00:39:42 +01:00
|
|
|
Text.insert_return(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
else
|
2022-07-13 00:39:42 +01:00
|
|
|
Text.insert_at_cursor(State, c)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
2022-08-17 17:36:17 +01:00
|
|
|
if Text.cursor_out_of_screen(State) then
|
2022-07-13 02:29:00 +01:00
|
|
|
Text.snap_cursor_to_bottom_of_screen(State, State.left, State.right)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-13 00:55:32 +01:00
|
|
|
record_undo_event(State, {before=before, after=snapshot(State, before_line, State.cursor1.line)})
|
2024-07-17 05:32:13 +01:00
|
|
|
schedule_save(State)
|
2022-07-12 06:14:59 +01:00
|
|
|
else
|
2022-12-24 01:16:19 +00:00
|
|
|
Text.keychord_press(State, chord)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
function edit.key_release(State, key, scancode)
|
2022-07-12 06:14:59 +01:00
|
|
|
end
|
2022-07-12 23:39:11 +01:00
|
|
|
|
2024-07-10 08:25:38 +01:00
|
|
|
function edit.update_font_settings(State, font_height, font)
|
2022-07-16 06:15:07 +01:00
|
|
|
State.font_height = font_height
|
2024-07-10 08:25:38 +01:00
|
|
|
State.font = font or love.graphics.newFont(State.font_height)
|
2022-07-16 06:15:07 +01:00
|
|
|
State.line_height = math.floor(font_height*1.3)
|
|
|
|
end
|
|
|
|
|
2022-07-16 06:12:25 +01:00
|
|
|
--== some methods for tests
|
|
|
|
|
2022-09-07 18:16:24 +01:00
|
|
|
-- Insulate tests from some key globals so I don't have to change the vast
|
|
|
|
-- majority of tests when they're modified for the real app.
|
2022-07-16 06:12:25 +01:00
|
|
|
Test_margin_left = 25
|
2022-09-07 18:16:24 +01:00
|
|
|
Test_margin_right = 0
|
2022-07-16 06:12:25 +01:00
|
|
|
|
|
|
|
function edit.initialize_test_state()
|
|
|
|
-- if you change these values, tests will start failing
|
|
|
|
return edit.initialize_state(
|
|
|
|
15, -- top margin
|
|
|
|
Test_margin_left,
|
2022-09-07 18:16:24 +01:00
|
|
|
App.screen.width - Test_margin_right,
|
2023-12-29 19:18:41 +00:00
|
|
|
love.graphics.getFont(),
|
2023-12-29 19:52:28 +00:00
|
|
|
14,
|
2022-07-16 06:12:25 +01:00
|
|
|
15) -- line height
|
|
|
|
end
|
2022-07-12 23:39:11 +01:00
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
-- all text_input events are also keypresses
|
2022-07-12 23:39:11 +01:00
|
|
|
-- TODO: handle chords of multiple keys
|
2022-12-24 01:16:19 +00:00
|
|
|
function edit.run_after_text_input(State, t)
|
|
|
|
edit.keychord_press(State, t)
|
|
|
|
edit.text_input(State, t)
|
|
|
|
edit.key_release(State, t)
|
2022-07-12 23:39:11 +01:00
|
|
|
App.screen.contents = {}
|
2022-12-13 06:31:45 +00:00
|
|
|
edit.update(State, 0)
|
2022-07-12 23:39:11 +01:00
|
|
|
edit.draw(State)
|
|
|
|
end
|
|
|
|
|
2022-12-24 01:16:19 +00:00
|
|
|
-- not all keys are text_input
|
2024-02-04 17:30:48 +00:00
|
|
|
function edit.run_after_keychord(State, chord, key)
|
|
|
|
edit.keychord_press(State, chord, key)
|
|
|
|
edit.key_release(State, key)
|
2022-07-12 23:39:11 +01:00
|
|
|
App.screen.contents = {}
|
2022-12-13 06:31:45 +00:00
|
|
|
edit.update(State, 0)
|
2022-07-12 23:39:11 +01:00
|
|
|
edit.draw(State)
|
|
|
|
end
|
|
|
|
|
2022-08-23 17:36:08 +01:00
|
|
|
function edit.run_after_mouse_click(State, x,y, mouse_button)
|
|
|
|
App.fake_mouse_press(x,y, mouse_button)
|
2022-12-24 03:26:05 +00:00
|
|
|
edit.mouse_press(State, x,y, mouse_button)
|
fix a crash involving mouse and drawings
Thanks Alex Schroeder for reporting this crash. The scenario:
* Edit a file like say this repo's Readme.
* The second line is empty and there's a '+' to insert a drawing.
Click on that.
* Resize the window so just the first line of text and the drawing are
visible.
* Close the window.
* Reopen lines.love, it will reopen the same file.
* Click on the left margin to the left of the drawing.
Before this commit these steps yielded the following crash:
Error: bad argument #1 to 'len' (string expected, got nil)
text.lua:626: in function 'pos_at_end_of_screen_line'
edit.lua:298: in function 'mouse_press'
There were two distinct problems here:
1. State.screen_bottom1 is not required to point to a text line, it
could just as well be a drawing. I have been sloppy in handling that.
2. The bug was partially masked (the need to close and reopen the
window) by a second bug: inserting a drawing was not invalidating the
cache I save of starty coordinates for each line. (I've inserted and
deleted starty invalidations a few times in the past, but it looks
like I'd never had one in this particular location edit.draw before.)
How did these issues get missed for years?
- Even though I use lines.love on a daily basis, it turns out I don't
actually create line drawings all that often.
- When I do, I'm still living in files that are mostly text with only
an occasional drawing.
- I keep my windows fairly large.
Between these 3 patterns, the odds of running into a drawing as the
first or bottom-most line on the screen were fairly small. And then I
had to interact with it. I suspect I tend to interact with drawings
after centering them vertically.
---
Bug #1 in particular has some interesting past history.
* Near the start of the project, when I implemented line-wrapping I
started saving screen_bottom, the bottom-most line displayed on
screen. I did this so I could scroll down easily just by assigning
`screen_top = screen_bottom`. (On the other hand, scrolling up still
required some work. I should perhaps get rid of it and just compute
scrolls from scratch each time.)
* Also near the start of the project, I supported selecting text by a
complex state machine spanning keypress, mouse press and mouse
release:
mouse click (press and immediate release) moves cursor
mouse drag (press and much later release) creates selection
shift-click selects from current cursor to click location
shift-movement creates/grows a selection
* On 2023-06-01, inscript reported a bug. Opening a window with just a
little bit of text (lots of unused space in the window), selecting all
the text and then clicking below all the text would crash the editor.
To fix this I added code at the bottom of edit.mouse_press which
computed the final visible line+pos location and used that in the
cursor-move/text-selection state machine. It did this computation
based on.. screen_bottom. But I didn't notice that screen_bottom could
be a drawing (which has no pos). This commit's bug/regression was
created.
* On 2023-09-20, Matt Wynne encountered a crash which got me to realize
I need code at the bottom of edit.mouse_release symmetric to the code
at the bottom of edit.mouse_press. I still didn't notice that
screen_bottom could be a drawing.
So in fixing inscript's bug report, I introduced (at least) 2
regressions, because I either had no idea or quickly forgot that
screen_bottom could point at a drawing.
While I created regressions, the underlying mental bug feels new. I just
never focused on the fact that screen_bottom could point at a drawing.
This past history makes me suspicious of my mouse_press/mouse_release
code. I think I'm going to get rid of screen_bottom entirely as a
concept. I'll still have to be careful though about the remaining
locations and which of them are allowed to point at drawings:
- cursor and selection are not allowed to point at drawings
- screen_top and screen_bottom are allowed to point at drawings
I sometimes copy between these 4 location variables. Auditing shows no
gaps where cursor could ever end up pointing at a drawing. It's just
when I started using screen_bottom for a whole new purpose (in
the mouse_press/release state machine) that I went wrong.
I should also try getting rid of starty entirely. Is it _really_ needed
for a responsive editor? I think I introduced it back when I didn't know
what I was doing with LÖVE and was profligately creating text objects
willy-nilly just to compute widths.
Getting rid of these two fairly global bits of mutable state will
hopefully make lines much more robust when the next person tries it out
in 6 months :-/ X-(
Thanks everyone for the conversation around this bug:
https://merveilles.town/@akkartik/112567862542495637
---
Bug #2 has some complexity as well, and might lead to some follow-on
cleanup.
When I click on the button to insert a new drawing, the mouse_release
hook triggers and moves the cursor below the new drawing. This is
desirable, but I'd never noticed this happy accident. It stops working
when I invalidate starty for all lines (which gets recomputed and cached
for all visible lines on every frame).
Fixing this caused a couple of unit tests start crashing for 2 reasons
that required their own minor fixes:
- My emulated mouse press and release didn't have an intervening
frame and so mouse_release no longer receives starty. Now I've added
a call to edit.draw() between press and release.
This might actually bite someone for real someday, if they're
running on a slow computer or something like that. I've tried to
click really fast but I can't seem to put mouse_press and release in
the same frame (assuming 30 frames per second)
- My tests' window dimensions often violate my constraint that the
screen always have one line of text for showing the cursor. They're
unrealistically small or have a really wide aspect ratio (width 2x
of height). I suspect lines.love will itself crash in those
situations, but hopefully they're unrealistic. Hmm, I wonder what
would happen if someone maximized in a 16:9 screen, that's almost
2x.. Anyways, I've cleaned a couple of tests up, but might need to
fix up others at some point. I'd have to rejigger all my brittle
line-wrapping tests if I modify the screen width :-/ X-(
2024-06-09 21:17:55 +01:00
|
|
|
edit.draw(State)
|
2022-08-23 17:36:08 +01:00
|
|
|
App.fake_mouse_release(x,y, mouse_button)
|
2022-12-24 01:16:19 +00:00
|
|
|
edit.mouse_release(State, x,y, mouse_button)
|
2022-07-12 23:39:11 +01:00
|
|
|
App.screen.contents = {}
|
2022-12-13 06:31:45 +00:00
|
|
|
edit.update(State, 0)
|
2022-07-12 23:39:11 +01:00
|
|
|
edit.draw(State)
|
|
|
|
end
|
|
|
|
|
2022-08-23 17:36:08 +01:00
|
|
|
function edit.run_after_mouse_press(State, x,y, mouse_button)
|
|
|
|
App.fake_mouse_press(x,y, mouse_button)
|
2022-12-24 03:26:05 +00:00
|
|
|
edit.mouse_press(State, x,y, mouse_button)
|
2022-07-12 23:39:11 +01:00
|
|
|
App.screen.contents = {}
|
2022-12-13 06:31:45 +00:00
|
|
|
edit.update(State, 0)
|
2022-07-12 23:39:11 +01:00
|
|
|
edit.draw(State)
|
|
|
|
end
|
|
|
|
|
2022-08-23 17:36:08 +01:00
|
|
|
function edit.run_after_mouse_release(State, x,y, mouse_button)
|
|
|
|
App.fake_mouse_release(x,y, mouse_button)
|
2022-12-24 01:16:19 +00:00
|
|
|
edit.mouse_release(State, x,y, mouse_button)
|
2022-07-12 23:39:11 +01:00
|
|
|
App.screen.contents = {}
|
2022-12-13 06:31:45 +00:00
|
|
|
edit.update(State, 0)
|
2022-07-12 23:39:11 +01:00
|
|
|
edit.draw(State)
|
|
|
|
end
|