capture.love/edit.lua

611 lines
22 KiB
Lua
Raw Normal View History

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}
Stroke_color = {r=0, g=0, b=0}
Current_stroke_color = {r=0.7, g=0.7, b=0.7} -- in process of being drawn
Current_name_background_color = {r=1, g=0, b=0, a=0.1} -- name currently being edited
Focus_stroke_color = {r=1, g=0, b=0} -- what mouse is hovering over
Highlight_color = {r=0.7, g=0.7, b=0.9} -- selected text
Icon_color = {r=0.7, g=0.7, b=0.7} -- color of current mode icon in drawings
Help_color = {r=0, g=0.5, b=0}
Help_background_color = {r=0, g=0.5, b=0, a=0.1}
Margin_top = 15
Margin_left = 25
Margin_right = 25
Drawing_padding_top = 10
Drawing_padding_bottom = 10
Drawing_padding_height = Drawing_padding_top + Drawing_padding_bottom
2022-07-13 05:38:29 +01:00
Same_point_distance = 4 -- pixel distance at which two points are considered the same
edit = {}
-- run in both tests and a real run
function edit.initialize_state(top, left, right, font, font_height, line_height) -- currently always draws to bottom of screen
local result = {
-- a line is either text or a drawing
-- a text is a table with:
-- mode = 'text',
-- string data,
-- a drawing is a table with:
-- mode = 'drawing'
-- a (h)eight,
-- an array of points, and
-- an array of shapes
-- a shape is a table containing:
-- a mode
-- an array points for mode 'freehand' (raw x,y coords; freehand drawings don't pollute the points array of a drawing)
-- an array vertices for mode 'polygon', 'rectangle', 'square'
-- p1, p2 for mode 'line'
-- center, radius for mode 'circle'
-- center, radius, start_angle, end_angle for mode 'arc'
-- Unless otherwise specified, coord fields are normalized; a drawing is always 256 units wide
-- The field names are carefully chosen so that switching modes in midstream
-- remembers previously entered points where that makes sense.
lines = {{mode='text', data=''}}, -- array of lines
-- Lines can be too long to fit on screen, in which case they _wrap_ into
-- multiple _screen lines_.
-- 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
-- fragments: snippets of the line guaranteed to not straddle screen lines
-- screen_line_starting_pos: optional array of grapheme indices if it wraps over more than one screen line
2022-07-21 00:34:09 +01:00
line_cache = {},
-- Given wrapping, any potential location for the text cursor can be described in two ways:
-- * 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.
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
selection1 = {},
-- some extra state to compute selection between mouse press and release
old_cursor1 = nil,
old_selection1 = nil,
mousepress_shift = nil,
-- cursor coordinates in pixels
cursor_x = 0,
cursor_y = 0,
current_drawing_mode = 'line', -- one of the available shape modes
previous_drawing_mode = nil, -- extra state for some ephemeral modes like moving/deleting/naming points
font = font,
font_height = font_height,
line_height = line_height,
top = top,
left = math.floor(left),
right = math.floor(right),
width = right-left,
filename = love.filesystem.getSourceBaseDirectory()..'/lines.txt', -- '/' should work even on Windows
next_save = nil,
-- undo
history = {},
next_history = 1,
-- search
search_term = nil,
search_backup = nil, -- stuff to restore when cancelling search
}
return result
end -- edit.initialize_state
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)
or edit.invalid_cursor1(State)
2023-03-17 16:36:38 +00:00
or not edit.cursor_on_text(State)
or not Text.le1(State.screen_top1, State.cursor1) then
State.screen_top1 = {line=1, pos=1}
2023-09-17 06:39:51 +01:00
State.cursor1 = {line=1, pos=1}
2023-09-15 16:46:36 +01:00
edit.put_cursor_on_next_text_line(State)
2023-03-17 16:36:38 +00:00
end
end
function edit.invalid1(State, loc1)
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
-- 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
2023-03-17 16:36:38 +00:00
function edit.cursor_on_text(State)
return State.cursor1.line <= #State.lines
and State.lines[State.cursor1.line].mode == 'text'
end
2023-09-15 16:46:36 +01:00
function edit.put_cursor_on_next_text_line(State)
while true do
2023-09-17 06:41:55 +01:00
if State.cursor1.line >= #State.lines then
break
end
if State.lines[State.cursor1.line].mode == 'text' then
break
end
State.cursor1.line = State.cursor1.line+1
State.cursor1.pos = 1
2022-07-24 07:36:04 +01:00
end
end
-- return y drawn until
function edit.draw(State)
State.button_handlers = {}
love.graphics.setFont(State.font)
2022-07-12 07:03:27 +01:00
App.color(Text_color)
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
local y = State.top
--? print('== draw')
for line_index = State.screen_top1.line,#State.lines do
local line = State.lines[line_index]
--? print('draw:', y, line_index, line)
if y + State.line_height > App.screen.height then break end
if line.mode == 'text' then
--? print('text.draw', y, line_index)
local startpos = 1
if line_index == State.screen_top1.line then
startpos = State.screen_top1.pos
end
if line.data == '' then
-- button to insert new drawing
button(State, 'draw', {x=State.left-Margin_left+4, y=y+4, w=12,h=12, bg={r=1,g=1,b=0},
icon = icon.insert_drawing,
onpress1 = function()
Drawing.before = snapshot(State, line_index-1, line_index)
table.insert(State.lines, line_index, {mode='drawing', y=y, h=256/2, points={}, shapes={}, pending={}})
2022-07-21 00:34:09 +01:00
table.insert(State.line_cache, line_index, {})
if State.cursor1.line >= line_index then
State.cursor1.line = State.cursor1.line+1
end
schedule_save(State)
record_undo_event(State, {before=Drawing.before, after=snapshot(State, line_index-1, line_index+1)})
end,
})
end
y = Text.draw(State, line_index, y, startpos)
--? print('=> y', y)
elseif line.mode == 'drawing' then
y = y+Drawing_padding_top
2022-07-21 01:06:16 +01:00
Drawing.draw(State, line_index, y)
y = y + Drawing.pixels(line.h, State.width) + Drawing_padding_bottom
else
assert(false, ('unknown line mode %s'):format(line.mode))
end
end
if State.search_term then
Text.draw_search_bar(State)
end
return y
end
function edit.update(State, dt)
2022-07-13 00:26:00 +01:00
Drawing.update(State, dt)
if State.next_save and State.next_save < Current_time then
2022-07-26 03:56:39 +01:00
save_to_disk(State)
State.next_save = nil
end
end
2022-07-13 00:30:41 +01:00
function schedule_save(State)
if State.next_save == nil then
State.next_save = Current_time + 3 -- short enough that you're likely to still remember what you did
end
end
function edit.quit(State)
-- make sure to save before quitting
if State.next_save then
2022-07-26 03:56:39 +01:00
save_to_disk(State)
-- give some time for the OS to flush everything to disk
love.timer.sleep(0.1)
end
end
2022-12-24 03:26:05 +00:00
function edit.mouse_press(State, x,y, mouse_button)
love.keyboard.setTextInput(true) -- bring up keyboard on touch screen
if State.search_term then return end
State.mouse_down = mouse_button
--? print_and_log(('edit.mouse_press: cursor at %d,%d'):format(State.cursor1.line, State.cursor1.pos))
2023-12-17 07:37:32 +00:00
if mouse_press_consumed_by_any_button(State, x,y, mouse_button) then
-- press on a button and it returned 'true' to short-circuit
return
end
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,
}
return
end
for line_index,line in ipairs(State.lines) do
if line.mode == 'text' then
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
-- i.e. mouse_release should never look at shift state
--? print_and_log(('edit.mouse_press: in line %d'):format(line_index))
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),
}
return
end
elseif line.mode == 'drawing' then
if Drawing.in_drawing(State, line_index, x, y, State.left,State.right) then
State.lines.current_drawing_index = line_index
State.lines.current_drawing = line
Drawing.before = snapshot(State, line_index)
2022-12-24 03:26:05 +00:00
Drawing.mouse_press(State, line_index, x,y, mouse_button)
return
end
end
end
-- still here? mouse press is below all screen lines
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)
end
function edit.mouse_release(State, x,y, mouse_button)
if State.search_term then return end
--? print_and_log(('edit.mouse_release: cursor at %d,%d'):format(State.cursor1.line, State.cursor1.pos))
State.mouse_down = nil
if State.lines.current_drawing then
Drawing.mouse_release(State, x,y, mouse_button)
2022-07-13 00:30:41 +01:00
schedule_save(State)
if Drawing.before then
record_undo_event(State, {before=Drawing.before, after=snapshot(State, State.lines.current_drawing_index)})
Drawing.before = nil
end
else
--? print_and_log('edit.mouse_release: no current drawing')
if y < State.top then
State.cursor1 = {line=State.screen_top1.line, pos=State.screen_top1.pos}
edit.clean_up_mouse_press(State)
return
end
for line_index,line in ipairs(State.lines) do
if line.mode == 'text' then
if Text.in_line(State, line_index, x,y) then
--? print_and_log(('edit.mouse_release: in line %d'):format(line_index))
State.cursor1 = {
line=line_index,
pos=Text.to_pos_on_line(State, line_index, x, y),
}
--? print_and_log(('edit.mouse_release: cursor now %d,%d'):format(State.cursor1.line, State.cursor1.pos))
edit.clean_up_mouse_press(State)
return
end
end
end
-- still here? mouse release is below all screen lines
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.cursor1 = Text.final_text_loc_on_screen(State)
edit.clean_up_mouse_press(State)
--? 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))
end
end
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
State.cursor1 = {line=State.screen_top1.line, pos=State.screen_top1.pos}
edit.put_cursor_on_next_text_line(State)
2023-03-24 04:00:09 +00:00
for i=1,math.floor(dy) do
Text.up(State)
end
elseif dy < 0 then
State.cursor1 = Text.screen_bottom1(State)
edit.put_cursor_on_next_text_line(State)
2023-03-24 04:00:09 +00:00
for i=1,math.floor(-dy) do
Text.down(State)
end
end
end
function edit.text_input(State, t)
2023-03-26 17:36:41 +01:00
--? print('text input', t)
if State.search_term then
State.search_term = State.search_term..t
Text.search_next(State)
2023-03-26 17:36:41 +01:00
elseif State.lines.current_drawing and State.current_drawing_mode == 'name' then
local before = snapshot(State, State.lines.current_drawing_index)
local drawing = State.lines.current_drawing
local p = drawing.points[drawing.pending.target_point]
p.name = p.name..t
record_undo_event(State, {before=before, after=snapshot(State, State.lines.current_drawing_index)})
else
2022-12-13 07:17:02 +00:00
local drawing_index, drawing = Drawing.current_drawing(State)
if drawing_index == nil then
Text.text_input(State, t)
2022-12-13 07:17:02 +00:00
end
end
2022-07-13 00:30:41 +01:00
schedule_save(State)
end
function edit.keychord_press(State, chord, key)
if State.selection1.line and
not State.lines.current_drawing and
-- 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
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
Text.delete_selection(State, State.left, State.right)
end
if State.search_term then
if chord == 'escape' then
State.search_term = nil
State.cursor1 = State.search_backup.cursor
State.screen_top1 = State.search_backup.screen_top
State.search_backup = nil
Text.redraw_all(State) -- if we're scrolling, reclaim all fragments to avoid memory leaks
elseif chord == 'return' then
State.search_term = nil
State.search_backup = nil
elseif chord == 'backspace' then
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)
elseif chord == 'down' then
State.cursor1.pos = State.cursor1.pos+1
Text.search_next(State)
elseif chord == 'up' then
Text.search_previous(State)
end
return
elseif chord == 'C-f' then
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
elseif chord == 'C-=' then
2022-07-16 06:15:07 +01:00
edit.update_font_settings(State, State.font_height+2)
Text.redraw_all(State)
elseif chord == 'C--' then
if State.font_height > 2 then
edit.update_font_settings(State, State.font_height-2)
Text.redraw_all(State)
end
elseif chord == 'C-0' then
2022-07-16 06:15:07 +01:00
edit.update_font_settings(State, 20)
Text.redraw_all(State)
2022-08-18 18:09:20 +01:00
-- undo
elseif chord == 'C-z' then
local event = undo_event(State)
if event then
local src = event.before
State.screen_top1 = deepcopy(src.screen_top)
State.cursor1 = deepcopy(src.cursor)
State.selection1 = deepcopy(src.selection)
patch(State.lines, event.after, event.before)
2022-07-21 00:34:09 +01:00
patch_placeholders(State.line_cache, event.after, event.before)
-- invalidate various cached bits of lines
State.lines.current_drawing = nil
-- if we're scrolling, reclaim all fragments to avoid memory leaks
Text.redraw_all(State)
2022-07-13 00:30:41 +01:00
schedule_save(State)
end
elseif chord == 'C-y' then
local event = redo_event(State)
if event then
local src = event.after
State.screen_top1 = deepcopy(src.screen_top)
State.cursor1 = deepcopy(src.cursor)
State.selection1 = deepcopy(src.selection)
patch(State.lines, event.before, event.after)
-- invalidate various cached bits of lines
State.lines.current_drawing = nil
-- if we're scrolling, reclaim all fragments to avoid memory leaks
Text.redraw_all(State)
2022-07-13 00:30:41 +01:00
schedule_save(State)
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}
elseif chord == 'C-c' then
local s = Text.selection(State)
if s then
App.set_clipboard(s)
end
elseif chord == 'C-x' then
local s = Text.cut_selection(State, State.left, State.right)
if s then
App.set_clipboard(s)
end
2022-07-13 00:30:41 +01:00
schedule_save(State)
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.
local before_line = State.cursor1.line
local before = snapshot(State, before_line)
local clipboard_data = App.get_clipboard()
for _,code in utf8.codes(clipboard_data) do
local c = utf8.char(code)
if c == '\n' then
Text.insert_return(State)
else
Text.insert_at_cursor(State, c)
end
end
2022-08-17 17:36:17 +01:00
if Text.cursor_out_of_screen(State) then
Text.snap_cursor_to_bottom_of_screen(State, State.left, State.right)
end
2022-07-13 00:30:41 +01:00
schedule_save(State)
record_undo_event(State, {before=before, after=snapshot(State, before_line, State.cursor1.line)})
-- dispatch to drawing or text
elseif App.mouse_down(1) or chord:sub(1,2) == 'C-' then
local drawing_index, drawing = Drawing.current_drawing(State)
if drawing_index then
local before = snapshot(State, drawing_index)
Drawing.keychord_press(State, chord)
record_undo_event(State, {before=before, after=snapshot(State, drawing_index)})
2022-07-13 00:30:41 +01:00
schedule_save(State)
end
elseif chord == 'escape' and not App.mouse_down(1) then
for _,line in ipairs(State.lines) do
if line.mode == 'drawing' then
line.show_help = false
end
end
2023-03-26 17:36:41 +01:00
elseif State.lines.current_drawing and State.current_drawing_mode == 'name' then
if chord == 'return' then
State.current_drawing_mode = State.previous_drawing_mode
State.previous_drawing_mode = nil
else
local before = snapshot(State, State.lines.current_drawing_index)
local drawing = State.lines.current_drawing
local p = drawing.points[drawing.pending.target_point]
if chord == 'escape' then
p.name = nil
record_undo_event(State, {before=before, after=snapshot(State, State.lines.current_drawing_index)})
elseif chord == 'backspace' then
local len = utf8.len(p.name)
2023-03-26 16:17:31 +01:00
if len > 0 then
local byte_offset = Text.offset(p.name, len-1)
if len == 1 then byte_offset = 0 end
p.name = string.sub(p.name, 1, byte_offset)
record_undo_event(State, {before=before, after=snapshot(State, State.lines.current_drawing_index)})
end
end
end
2022-07-13 00:30:41 +01:00
schedule_save(State)
else
Text.keychord_press(State, chord)
end
end
function edit.key_release(State, key, scancode)
end
2022-07-16 06:15:07 +01:00
function edit.update_font_settings(State, font_height)
State.font_height = font_height
State.font = love.graphics.newFont(State.font_height)
2022-07-16 06:15:07 +01:00
State.line_height = math.floor(font_height*1.3)
end
--== 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.
Test_margin_left = 25
2022-09-07 18:16:24 +01:00
Test_margin_right = 0
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,
love.graphics.getFont(),
14,
15) -- line height
end
-- all text_input events are also keypresses
-- TODO: handle chords of multiple keys
function edit.run_after_text_input(State, t)
edit.keychord_press(State, t)
edit.text_input(State, t)
edit.key_release(State, t)
App.screen.contents = {}
edit.update(State, 0)
edit.draw(State)
end
-- not all keys are text_input
function edit.run_after_keychord(State, chord, key)
edit.keychord_press(State, chord, key)
edit.key_release(State, key)
App.screen.contents = {}
edit.update(State, 0)
edit.draw(State)
end
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)
App.fake_mouse_release(x,y, mouse_button)
edit.mouse_release(State, x,y, mouse_button)
App.screen.contents = {}
edit.update(State, 0)
edit.draw(State)
end
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)
App.screen.contents = {}
edit.update(State, 0)
edit.draw(State)
end
function edit.run_after_mouse_release(State, x,y, mouse_button)
App.fake_mouse_release(x,y, mouse_button)
edit.mouse_release(State, x,y, mouse_button)
App.screen.contents = {}
edit.update(State, 0)
edit.draw(State)
end