From f231f62f5261b504236d6718c1ef9e93d2449f0c Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sat, 12 Sep 2026 13:26:38 +0700 Subject: [PATCH] Globals go per frame; watching is its own question --- DISCUSS.md | 36 ++++++++++++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/DISCUSS.md b/DISCUSS.md index 760abb9..56427c0 100644 --- a/DISCUSS.md +++ b/DISCUSS.md @@ -19,8 +19,17 @@ the machinery is there and the question is mostly one of presentation — its ow the stack, or a separate buffer. The real question is **which** globals. A program has hundreds and a listing of all of them is the backtrace problem -again: the thing you want is buried by the thing you don't. Worth considering: only globals the stopped function -mentions, which the compiler knows; or a filter; or a pinned watch list. +again: the thing you want is buried by the thing you don't. + +**Direction settled in conversation: per frame, beside the locals.** Opening a frame shows that function's locals *and* +the globals that function references. Each frame answers for itself — frame 0 shows what the innermost function touched, +frame 3 shows what that one touched, and a global appearing in several frames is informative rather than redundant, +because it says the whole chain was working with it. The compiler already knows the reference set per function, so +nothing is guessed and nothing is configured. + +What this deliberately does not solve: a global nothing in the current frame names but that you still want visible — +the sand grid while stopped in a helper that never mentions it. That is watching, and it is item 10 rather than part of +this. ## 2. The break buffer should appear by itself @@ -132,3 +141,26 @@ Three findings from an earlier review, recorded in `NEXT.md` and not yet in `pla Also open and related: whether a *condition* can be a class, which decides whether handler matching has one path or two. `NEXT.md` records the argument; decision 4 there took the cheaper parent-link route for now and explicitly left real inheritance possible later. + +## 10. Watching variables + +Raised while designing item 1, and deliberately separated from it. + +Item 1 shows globals *per frame*, chosen by what the code in that frame references. That is the right default and it +cannot cover the case where the thing you care about is not named by the frame you are standing in — stopped deep in a +helper, still wanting to see the grid. + +So: a way to say "always show me this", surviving a resume and the next break. + +Questions it opens: + +- **What can be watched.** A global is easy — it has a name and an address that does not move. A *local* is harder: it + belongs to a frame that is gone as soon as you resume, so "watch `y`" either means a different `y` every time or means + nothing. A watched expression — `(at velocity 40 12)` — is the most useful and the most expensive, since it has to be + compiled and run in the program each time, which is what `eval-expr` already does. +- **Where the list lives.** Per project, per session, or in the file. A watch list that vanishes when Emacs restarts is + one you stop using; one in the repo is one you accidentally commit. +- **When it updates.** Only on entering a break is cheap and probably enough. Live-updating while the program runs is a + different feature — closer to a HUD than a debugger — and worth not conflating. +- **Whether it belongs in the break buffer at all**, or in its own window that is useful while the program is *running*, + which is arguably where a game developer wants it.