snap.love/0019-B

26 lines
690 B
Plaintext
Raw Permalink Normal View History

snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
B = function()
2023-10-25 14:45:09 +00:00
-- recompute various aspects based on the current viewport settings
for _,obj in ipairs(Surface) do
if obj.type == 'line' then
obj.zdata = {}
for i=1,#obj.data,2 do
table.insert(obj.zdata, vx(obj.data[i]))
table.insert(obj.zdata, vy(obj.data[i+1]))
end
elseif obj.type == 'bezier' then
zdata = {}
for i=1,#obj.data,2 do
table.insert(zdata, vx(obj.data[i]))
table.insert(zdata, vy(obj.data[i+1]))
end
obj.zdata = love.math.newBezierCurve(zdata):render()
elseif obj.type == 'text' then
if obj.w then
snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
update_editor_box(obj)
2023-10-25 14:45:09 +00:00
else
obj.text = love.graphics.newText(love.graphics.getFont(), obj.data)
end
end
end
end