| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scenario:
- create a long wrapping line
- tap past end of first screen line
Before this commit the cursor would be positioned not quite at the end
of the screen line but one character before. In effect there was no way
to position cursor at end of a wrapping line.
I'm not sure how this bug has lasted so long. It was introduced in
commit 8d3adfa36 back in June 2022, which was itself billed as a bugfix
for "clicking past end of screen line". But when I go back to it this
bug exists even back then. How did I miss it?! I wrote a test back then
-- and the test was wrong, has always been wrong.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is all quite hacky. Many of my tests are unfortunately brittle to
changes in text rendering. Fortunately there's only one test that
currently requires a hacky special case (and a second test I tweaked
slightly to be more robust).
I can't think of a better approach. It doesn't help to standardize the
font, because version changes still come with changes to text-shaping
algorithms even if the font itself is unchanged. I could base all my
assertions on the widths of individual characters, but that would make
the tests much less readable and not express intent as clearly. So here
we are, with hopefully just a few hacky special cases (there might be a
few more as LÖVE v12 advances towards publication, and in further
versions).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Before this change the cursor was moving, but not being highlighted
properly when the cursor line contained unicode before the cursor.
|
| |
|
|
| |
Also copy over the implementation of links from pensieve.love.
|
| | |
|
| |
|
|
| |
Thanks Mikoláš Štrajt.
|
| |
|
|
| |
This bug was introduced in commit 528c64d690 on 2022-09-05 :/
|
| | |
|
| | |
|
| |
|
|
|
| |
I want the words to be easy to read, and to use a consistent tense.
update and focus seem more timeless; let's make everything like those.
|
| | |
|
| | |
|
| |
|
|
|
| |
I've only tested side A so far, and included a statement of how I want
side B to behave.
|
| | |
|
|
|
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|