| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
| |
This is a holdover from the days of bifold text.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Seeing a partial item can nudge someone to try resizing the window and
so learn about more shortcuts.
|
|
|
|
|
| |
I'm not going to save this MRU order across sessions for now. It's good
enough to save cursor positions for individual files, I think.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
I'm starting to use logging, but it's still easier to print textual logs.
|
| |
|
|
|
|
|
| |
We still don't have up/down arrow keys. And we still don't have the
ability to filter filenames by typing.
|
| |
|
|
|
|
|
|
|
| |
One open question is how to manage logs while drawing, since they can be
extremely verbose. Neither tags nor depths seem like the right metaphor
here, and that gives me pause that I perhaps don't see the full space of
needs yet.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
I've been running out of ctrl+ shortcuts, and I just remembered my
original idea to keep ctrl+ for drawings/mouse operations and alt+ for
everything else.
|
| |
|
|
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|