scenario: run without config file, quit, run again
expected: font size remains the same on second run
Before this commit it was increasing on each run.
It turns out the font height that you pass into love.graphics.newFont()
is not the result of font:getHeight().
Future writes would fail anyway.
(In the past, relative paths have referred to the save dir. The natural
expectation is current working dir. So I'm not going to try to guess.)
This only happens when pressing C-n inside a drawing in normal (not
maximized) mode.
The reason is complicated. First, the baseline:
* When pressing C-o:
run.keychord: starty is not nil
run.keychord: current drawing is nil
Drawing.keychord C-o: doesn't set current drawing
plan_draw (only happens in normal mode): clears starty in all lines
Drawing.update: all good ✓
* When pressing C-n:
run.keychord: starty is not nil
run.keychord: current drawing is nil
Drawing.keychord C-n: sets current drawing <===
plan_draw: clears starty in all lines
Drawing.update: BOOM
Ugh.
When is starty set? Drawing.draw. This is why I can clean it up with
abandon. But:
frame = events -> update -> draw
* plan_draw clears starty while processing events
* Drawing.update blows up in here <===
* Drawing.draw is about to set starty
So one possible interpretation here is that this is an unfortunate
interaction of two special-cases:
* draw should never mutate state, but it's just the most convenient
place to track starty
* keystrokes never set current drawing -- except rare operations like
naming and moving points
So the current prescription: any code called from within update needs to
protect against starty being nil.
Ugh X-(
Before:
- notes directory is saveDir/data by default
where saveDir = love.filesystem.getSaveDirectory()
- providing a commandline arg of x makes the notes directory saveDir/data.x
Now:
- there is no default directory; you get an error message instead
telling you what to do.
- the commandline arg is the (preferably absolute) path of the notes
directory you want to load
Unchanged: once you set the notes directory it gets remembered for
future runs.
Now the Readme is a lot simpler.
I tried to make migrating simpler, but this is complicated enough (see
Manual_tests.md)
Now pensieve.love always manages notes in the data/ subdirectory of the
save dir, and stores its settings in the 'config' file in the save dir.
And main.lua is now much more similar to upstream and most forks. I made
this edit using an external editor, just to keep the comparison with
lines.love in view.
Being smart about the y coordinate is difficult, so they just bounce to
top of column for now. That way we're guaranteed the cursor pane will be
on screen.
I'm learning the hard way that resizing the window is a big deal. Only
do this when someone explicitly requests it, otherwise follow LÖVE's
defaults.
Therefore we're also going to stop trying to be smart when showing the
log browser. Leave window resizing to manual operations.
Now initialization looks a lot more similar for the run and source apps.
I just noticed we hadn't got this bugfix for Linux on the main app. How
had we not noticed this issue before? Answer: lines.love windows tend to
be tall and skinny, and resize must keep the window entirely within the
screen. So the window was staying in place just because it happened to
be running up against the bottom.
Before this commit it was scrolling up too much. Like, 2 screens up
instead of 1.
This commit seems like a follow-up to commits dabb7a6c4 and a9a8d5c17.
I'm not analyzing it too much, just focusing on this location after some
debug logs.
Those commits should probably have noticed the missing symmetric
keystroke. But I'm probably ignoring similar concerns in dealing with
this so superficially.
Scenario: press C-f and search for something.
Some of the time we get a crash with this call stack:
Error
text.lua:970: attempt to compare nil with number
Traceback
[love "callbacks.lua"]:228: in function 'handler'
text.lua:970: in function 'lt1'
search.lua:72: in function 'search_next'
run.lua:985: in function 'search_next_in_pane'
run.lua:939: in function 'search_next'
run.lua:784: in function 'text_input'
main.lua:237: in function <main.lua:230>
app.lua:31: in function <app.lua:22>
[C]: in function 'xpcall'
Not fixed yet.
The cause: plan_draw is conservative and sometimes tries to render panes
that never overlap the viewport.
This bug was exacerbated by fixing the inscript bug which started
setting screen_bottom1 to nil. But the problem existed before as well,
we just operated on stale screen_bottom1 locations.
This bug doesn't generalize to many other scenarios. It isn't a problem
for forks without the surface metaphor, though it might affect
driver.love as well. Even in pensieve.love, the only place that uses
screen_bottom while spanning multiple editors is find across the entire
surface.
The bug has been spotted twice:
1. In snap.love, I selected text in one node, then another, and hit:
Error: text.lua:789: attempt to compare nil with number
stack traceback:
text.lua:789: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:32: in function 'draw'
edit.lua:117: in function 'draw'
[string "REPL"]:21: in function 'draw'
main.lua:152: in function 'draw'
app.lua:102: in function <app.lua:84>
[C]: in function 'xpcall'
app.lua:112: in function <app.lua:111>
[C]: in function 'xpcall'
Couldn't reproduce.
2. In text.love, inscript selected all text in a small buffer and then
clicked outside the text. And got:
Error: text.lua:784: attempt to compare nil with number
Traceback
[love "callbacks.lua"]:228: in function 'handler'
text.lua:784: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:27: in function 'draw'
edit.lua:117: in function 'draw'
run.lua:136: in function 'draw'
main.lua:148: in function 'draw'
app.lua:42: in function <app.lua:22>
[C]: in function 'xpcall'
This is reproducible, and also across forks.
Kartik K. Agaram