| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
To fix this I have to first stop incrementally updating screen_bottom1
in the middle of a frame. Now it always has a good value from the end of
a frame.
I'm also running into some limitations in the test I'd ideally like to
write (that are documented in a comment), but I still get some sort of
automated test for this bugfix.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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
|
| | |
|
| |
|
|
| |
Also copy over the implementation of links from pensieve.love.
|
| |
|
|
|
|
| |
This doesn't affect this fork directly, but it's a bad idea to assume
the _app_ is always going to be doing just what a particular subsystem
(here, the text editor in edit.lua+text.lua) is doing.
|
| | |
|
| |
|
|
|
|
|
| |
Now we render lines one screen line at a time rather than one word at a
time.
I can't port the source side just yet; I need to fix hyperlinks first..
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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 pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|
| |
|
|
|
| |
In general it seems like good practice to minimize assumptions about
the current color.
|
| | |
|
| | |
|
| |
|
|
| |
Luckily they didn't bite me yet.
|
| |
|
|
|
|
| |
I guess I wrote it before I settled into the idiom of:
* first change cursor
* then scroll if necessary
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm taking some lessons from pensieve.love here. It seem like specific
pixel thresholds don't matter too much for plain lines.love.
I'd probably feel safer if I just used Text.cursor_out_of_screen in
these places, but it means we draw the screen twice for most events[1].
Let's see if we can get by with the current approach.
[1] Or we have to start scheduling things for the next draw, which is
more complex to orchestrate.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The way Text.draw is called by edit.draw, we know it'll never be called
for lines above screen_top1.line. Comparing every line on screen with
screen_top1 makes no sense. The intent is really just to compare with
screen_top1 only for the first line, and otherwise to ignore this check.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Broken since commit 188bbc73 9 days ago :/ At least we have a test for
it now.
|