| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This is stupid; I did it right in pensieve.love to begin with.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Selecting text is also almost done. I just need to figure out what to do
with bifold text.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
scenario: open app from .love file, press ctrl+e
Before this change the source file showed up empty.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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
|
|
|
|
|
| |
Before this commit I was propagating press events only if _all_ buttons
would.
|
| |
|
|
|
|
|
| |
In general it seems like good practice to minimize assumptions about
the current color.
|
| |
|
| |
|
|
|
|
| |
Now missing files will result in similar behavior: nil file handles.
|
| |
|
| |
|
|
|
|
|
|
| |
This is compatible with Javascript, and it also seems like a better
default; when people forget to think about return values in click
handlers, they should be consumed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symptom: a test (test_click_to_create_drawing) started randomly failing
after I inserted a `return` 2 commits ago.
Cause: my tests call edit.draw, but button handlers only get cleared in
app.draw. So my tests weren't clearing button handlers, and every call
to edit.draw was accumulating states. Still unclear why those were going
to different state objects after the `return`, but anyway. I'm not going
to understand every last thing that happens when things go wrong, just
guarantee they can't go wrong. And the way to do that is to decentralize
button handlers to each state that receives them.
The State object in buttons.lua doesn't have to be Editor_state. It just
has to be some table that provides a Schelling Point for shared state.
|
| |
|