| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
I'm not sure this can trigger everywhere (I've only been able to
exercise it in Lua Carousel), but it seems like a safety net worth
having against future modifications by anybody.
|
|
|
|
|
|
|
| |
This commit doesn't guarantee we'll always catch it. But if this
invariant is violated, things can get quite difficult to debug. I found
in the Lua Carousel fork that all the xpcalls I keep around were
actively hindering my ability to notice this invariant being violated.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
|
| |
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 :/
|
|
|
|
|
| |
This keeps things consistent with other forks (links, lines-and-links)
that are "conceptually upstream" of the source editor.
|
| |
|
|
|
|
| |
In addition to being more efficient, this will simplify the next bugfix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
scenario:
* position a wrapped line on screen
* search for the word immediately after the point of wrapping
Before this commit the word would be highlighted twice:
- at the end of the first screen line
- at the start of the second screen line
Now it shows up at the right place.
|
|
|
|
|
|
| |
I'm duplicating the bounds check when drawing cursor and search
highlight because they're separate concerns and require subtly different
logic.
|
| |
|
| |
|
|
|
|
|
| |
I added this to catch a rare bug. I've had it locally for a few weeks
now without hitting it. Doesn't hurt to publish it.
|
|
|
|
|
|
| |
Scenario: a long line containing a hyperlink towards the end.
Before this commit the underline for the hyperlink was being rendered on
an x pixel starting from the start of the line.
|
|
|
|
|
|
| |
This is a violation of an existing rule in Manual_tests.md. The
following command weakly suggests there aren't any others:
grep ':sub(' *.lua |grep pos
|
|
|
|
|
|
|
|
|
|
|
|
| |
A code editor is unlikely to need support for extremely long lines. And
that kind of scroll is jarring anyway in a code editor. We don't read
code like a novel, and less scroll per page implies more scrolling work.
I'd gotten rid of this functionality and the test for it [1] back in the
spokecone fork, but only took out the test when first pulling it into
the source editor.
[1] test_pagedown_often_shows_start_of_wrapping_line
|
| |
|
|
|
|
|
|
|
| |
I missed that comments only get highlighted at start of line.
This seems a bit hacky. But it continues to trade off CPU for reduced
memory footprint.
|
|
|
|
| |
Also copy over the implementation of links from pensieve.love.
|
|
|
|
|
|
|
|
|
|
| |
I think all we need to maintain is the populate_screen_line_starting_pos
array. It's easy to render screen lines one by one from it, and we'll
only ever construct one additional screen line at a time.
I'd hoped to delete other calls to Text.populate_screen_line_starting_pos,
but it turns out we need to update it when editing sometimes. Give up on
that for now; it's a no-op if not needed.
|
| |
|
|
|
|
|
| |
It's starting to become apparent just how little line_cache.fragments
does for me now. Let's see if we can get rid of it entirely.
|
|
|
|
| |
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've been misunderstanding what Text objects are. They can render a lot
of text with a given line height, word wrap, colors in various places.
And I've been creating one for every word :facepalm:
Unwinding this will take some time. This is just a first baby step for
ad hoc text objects. Turns out I don't need to convert to Text to get
something's rendered width, just the Font can do that.
Thanks to the LÖVE Discord for educating me:
https://discord.com/channels/329400828920070144/330089431379869708/1091535487333826580
|
| |
|
|
|
|
| |
Don't crash on showing the log browser.
|
|
|
|
| |
Thanks Mikoláš Štrajt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
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 the pensieve fork.
|
| |
|
|
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|