| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This repo does not support freewheeling modification. It's a primitive
to enable freewheeling modification in downstream forks.
The source editor is a convenience, but it's a sharp tool and can easily
leave the app in a broken state that requires dropping down to external
tools (editor, file manager) to fix.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scenario: open a file starting with a drawing
After this commit the program doesn't crash.
Error: [string "edit.lua"]:127: attempt to get length of field 'data' (a nil value)
stack traceback:
[love "boot.lua"]:345: in function '__len'
[string "edit.lua"]:127: in function 'invalid1'
[string "edit.lua"]:116: in function 'check_locs'
[string "run.lua"]:35: in function 'initialize'
main.lua:96: in function 'initialize'
[string "app.lua"]:144: in function 'run_tests_and_initialize'
[string "app.lua"]:16: in function <[string "app.lua"]:13>
[C]: in function 'xpcall'
[love "boot.lua"]:361: in function <[love "boot.lua"]:348>
[C]: in function 'xpcall'
|
| |
|
| |
|
| |
|
|
|
|
| |
https://merveilles.town/@akkartik/110084833821965708
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Many thanks to Myte for helping test this!
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This works better on mobile platforms while seeming about as useful
anywhere else.
I've verified that anyone who already edited a file will continue to use
its path from settings.
|
| |
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
Thanks Mikoláš Štrajt.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
scenario:
press ctrl+f, type in a string
hit down arrow if needed until the screen scrolls
press enter
click with the mouse somewhere
Before this commit the app would crash because cursor was above screen
top.
|
| |
|
|
|
|
| |
This bug was introduced in commit 528c64d690 on 2022-09-05 :/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently only used in pong.love, but let's keep the bad merge that had
it broken since September from occurring again. To do that we'll be
consistent across forks on where globals are initialized.
I haven't appreciated the implications of main.lua for load order.
log.lua comes first just because it's shared by both the main app and
its 'source' editing environment. And it just so happens that source.lua
was loading after log.lua resulting in the pong.love breakage. Now let's
lean into that and enshrine that one should initialize log_render in
log.lua.
|