| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seemingly simple goal uncovered a little nest of bugs: it turns out
I've been awash in ambiguous labels until now. My baseline recipes in
edit.mu were clean, but they introduced duplicate <waypoints> -- and
*those* waypoints contained +jump-targets. Result: duplicate jump
targets, so that I wasn't jumping where I thought I was jumping. Somehow
I happened to be picking one of the alternatives that magically kept
these issues quiescent.
My first plan to fix this was to mangle names of all labels inside
before/after fragments, keep the jump targets private to their fragment.
But the labels also include more waypoints! Mangle those, and I can't
tangle to them anymore.
Solution: harden the convention that jump targets begin with '+' and
waypoints are surrounded by '<>'. Mangle jump targets occurring inside
before/after fragments to keep them private to their lexical fragment,
but *don't* mangle waypoints, which must remain globally accessible.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
| |
|
|
|
|
| |
Turns out it is indeed useful to insert code at multiple duplicate
labels within a single (long) recipe. Like handle-keyboard-event in
edit.mu.
|
| |
|
|
| |
However, you can't have duplicate labels within a single recipe.
|
| | |
|
| |
|