| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
I'm learning the hard way that resizing the window is a big deal. Only
do this when someone explicitly requests it, otherwise follow LÖVE's
defaults.
Therefore we're also going to stop trying to be smart when showing the
log browser. Leave window resizing to manual operations.
Now initialization looks a lot more similar for the run and source apps.
|
|
|
|
| |
Initialization is getting complex, and I'm finding bugs.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Also copy over the implementation of links from pensieve.love.
|
|
|
|
|
| |
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
|
|
|
|
| |
https://merveilles.town/@akkartik/110084833821965708
|
| |
|
|
|
|
| |
Many thanks to Myte for helping test this!
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
This way we can have the log side actually take focus sometimes.
|
|
|
|
|
| |
This time we have to handle absolute filenames.
Now lines-polygon-experiment fork should merge successfully, at least.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm a bit leery of going down this road:
- If there's a bug in how I render logs graphically that could be
extremely misleading. Perhaps this suggests that the code to log
things should be significantly simpler than the code that might be
debugged. If writing the debug helper requires all my smarts I'm not
smart enough to debug using the helper, etc. Given this idea, the fact
that I'm copying production code into the logging helper is
concerning.
- There's a question of what code it's ok for logging helpers to depend
on. This is an issue shared with tests. I often implicitly (and
without meaning to) assume the presence of some well-tested helpers
when writing tests. If those helpers ever break I can get into a
rabbit hole of debugging. This problem might be even more insidious
with logging helpers that will give me no indication when they break.
Still and all, it's cool to see menus in my logs. Let's see if it's
useful.
|
|
|
|
| |
This is stupid; I did it right in pensieve.love to begin with.
|
|
|
|
|
|
|
|
| |
In the fullness of time, I'll want to remember previous file, type to
filter, etc. But for now just don't forget where you were. This is
helpful because I'm often working on either the run side or the source
side, and just starting out on the right side shaves off a lot of
keypresses.
|
|
|
|
|
|
| |
I'm starting to edit the sources from within the app in ernest. First
question: why does the file navigation menu skip some files? These
prints answer the question.
|
| |
|
| |
|
|
|
|
| |
Running the tests now uglily resizes the window for a second or two.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The main app shows the file being edited, but the programming environment does not.
|
|
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|