| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Avoid accidental side-effects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is ancient and it affects every single one of my forks,
including the whole lines2 lineage. The corner case: searching for empty
string.
In the process I've also cleaned up edit.check_locs on initialization to
only modify cursor if it can find a legal place for it.
In general I should be more careful about mutating the cursor. Just
adding 1 to it is irresponsible.
|
|
|
|
| |
Ported from bugfix of 2024-06-23.
|
| |
|
| |
|
|
|
|
| |
This isn't a bug here, but it led to a bug in lines 2.
|
| |
|
|
|
|
|
| |
We're patching line_cache and then immediately clearing it using
Text.redraw_all.
|
| |
|
|
|
|
| |
It's shorter and conveys intent better.
|
|
|
|
|
| |
This is quite useful because I used to have a long list of places in
which to invalidate the cache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure this is very useful. I had an initial idea to stop using
screen_bottom1 in final_text_loc_on_screen, by starting from screen_top1
rather than screen_bottom1. But that changes the direction in which we
scan for the text line in situations where there is somehow no text on
screen (something that should never happen but I have zero confidence in
that).
Still, it doesn't seem like a bad thing to drastically reduce the
lifetime of some derived state.
Really what I need to do is throw this whole UX out and allow the cursor
to be on a drawing as a whole. So up arrow or left arrow below a drawing
would focus the whole drawing in a red border, and another up arrow and
left arrow would skip the drawing and continue upward. I think that
change to the UX will eliminate a whole class of special cases in the
code.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- source editor always expects relative paths
- refresh mocked data
There's still one issue after this: the font size saved in the config
file is the one we use in tests. More broadly, Editor_state is
completely wrong.
Ideally I'd just not save any settings for the source editor if the
tests fail.
|
| |
|
|
|
|
|
|
|
|
|
| |
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().
|
|
|
|
|
| |
Now it adjusts the current font for itself.
And it's up to the caller to adjust the current font after.
|
| |
|
|
|
|
|
|
|
|
|
| |
We'll end up calling Text.redraw_all anyway, which will clear starty and
much more besides.
We'll still conservatively continue clearing starty in a few places
where there's a possibility that Text.redraw_all may not be called. This
change is riskier than most.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each one should provide a message that will show up within LÖVE. Stop
relying on nearby prints to the terminal.
I also found some unnecessary ones.
There is some potential here for performance regressions: the format()
calls will trigger whether or not the assertion fails, and cause
allocations. So far Lua's GC seems good enough to manage the load even
with Moby Dick, even in some situations that caused issues in the past
like undo.
|
|
|
|
|
|
| |
Make it more obvious that the color passed in is just for the background.
The icon will do the rest.
r/g/b keys are more consistent with App.color().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Matt Wynne pointed out that snap.love would crash when a node went off
screen. While debugging it I noticed that selection1 was being set when
it shouldn't be.
Turns out I introduced a bug when I fixed the inscript bug back in June
(commit 9656e137742). One invariant I want to preserve is: selection1
should be unset after a mouse click (press and release without
intervening drag). This invariant was violated in my bugfix back in
June. I was concerned only with selection back then, and I didn't
realize I was breaking the mouse click case (in a fairly subtle way; you
can have selection set, and when it's set identically to the cursor
everything looks the same).
I think there might still be an issue in snap.love after this fix. I
noticed screen_bottom1.pos was nil, and as far as I recall that should
never happen.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the Text functions assume the cursor is always on a text line. I was
violating that invariant.
* When scrolling up, I start the cursor at the top-most line below the
screen top.
* When scrolling down, I start the cursor at the top-most line below the
screen bottom.
I think it would feel slightly more natural for it to be the
bottom-most line above the screen bottom.
However, the Text functions maintain an invariant that the bottom-most
line in a buffer will be text. There's no such invariant for the
top-most line.
|
| |
|
|
|
|
|
|
| |
The drawing buttons are now absolutely positioned, which is a horrible
hack. But for just the source editor it seems good enough. The
alternative is to modify magic constants in all the tests :/
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scenario:
* start out with some text on screen
* select some text A, delete
* select some more text B, delete
* press C-z twice to restore A and B
* press C-y twice
Before this commit only the first C-y was having an effect (deleting B).
The second was failing to delete A.
|
|
|
|
| |
Also copy over the implementation of links from pensieve.love.
|
|
|
|
|
|
| |
I see a path to at least maintain a single fragment per screen line. But
can we do better? It even seems unnecessary to maintain two copies of
the data, chopped up into lines and screen lines.
|
|
|
|
| |
Is it just my imagination, or does the app feel lighter and more fluffy?
|
|
|
|
|
| |
In the process I discovered the horrible fact that Text.x allocates a new Text.
And it gets called (just once, thank goodness) on every single frame.
|
| |
|
| |
|
|
|
|
|
| |
I can't see the mouse wheel ever setting dx, but it's more obvious now
that the editor doesn't support panning left/right.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's just uneconomic to maintain given how little I've used it. I have a
bug right now and no time to port the bugfix to all the complexities of
the B side.
I briefly considered tossing out the entire source editor. But I _have_
been using it to browse logs across sessions. The live editor doesn't
quite cover all my use cases just yet.
We now have duplication in the source editor only for:
* syntax highlighting
* hyperlinking [[WikiWords]]
* ability to hide cursor (when showing file browser or Focus is in log browser)
|
| |
|
|
|
|
| |
Thanks Mikoláš Štrajt.
|
| |
|