d regs -> mdesk

src/raddbg/raddbg.h

@@ -3,47 +3,49 @@
 
 ////////////////////////////////
 //~ rjf: Frontend/UI Pass Tasks
-//
-// [ ] engine/frontend commands situation
-//  - currently, there is an interesting bifurcation of commands in the
-//    frontend; you can either push a command *at a root level*, or push a
-//    command to a locally-accessible list if you want that command to run
-//    on the same frame (root level commands are deferred by a frame, since
-//    the engine must see them first).
-//  - things would be simpler if there was only a single "push command"
-//    mechanism, and codepaths only ever saw these commands at most once.
-//    this would require an alternate strategy of the initial "gather" of
-//    commands, and instead it would just be a global queue, or something...
-//    it is a little weird since commands are not just consumed in order...
-//  - this will clean up the various different ways that codepaths
-//    parameterize commands.
-// [ ] frontend entities vs. engine entities
-//  - currently, the engine has entities like "watch", and the frontend
-//    has entities like "windows", "panels", and "views".
-//  - because "watch" entities ideally have a hierarchical relationship
-//    with windows, panels, and views (enabling things like drag/drop
-//    from watch window -> tab, or tab -> watch window, trivially), it
-//    would be much better if all entities could collapse into engine
-//    entities.
-//  - now, the frontend requires various specialized resources for things
-//    like windows, so what I am thinking is that the engine just controls
-//    all of the stateful windows/panel/view/watch mechanisms, and then
-//    the frontend pure-functionally queries stuff like os/r handles
-//    on-demand, and then prunes them, immediate-mode cache style.
-// [ ] command params -> d_regs
-//  - currently there are two almost-identical concepts relating to commands:
-//    the parameters struct, and D_Regs. D_Regs is a registers struct which
-//    is used to manage a stack of contextual information in various debugger
-//    codepaths. it is used so that codepaths can register information they
-//    know about, without passing it down to everyone explicitly - but those
-//    later codepaths can still pass that information along. e.g. a window
-//    calls into a watch window, watch window calls into visualizer, visualizer
-//    pushes command, which needs to pass which window it occurred on along.
-//  - i think D_Regs needs to expand a bit in order to encompass all of the
-//    things that the command parameters were being used for, but at that point
-//    commands can just be a spec * regs, and then the push-command API can
-//    just have ways of overriding regs values explicitly, when the codepath
-//    needs to be opinionated about which things are affected by which commands
+//
+// [ ] empty user file causing failure to launch
+//
+// [ ] engine/frontend commands situation
+//  - currently, there is an interesting bifurcation of commands in the
+//    frontend; you can either push a command *at a root level*, or push a
+//    command to a locally-accessible list if you want that command to run
+//    on the same frame (root level commands are deferred by a frame, since
+//    the engine must see them first).
+//  - things would be simpler if there was only a single "push command"
+//    mechanism, and codepaths only ever saw these commands at most once.
+//    this would require an alternate strategy of the initial "gather" of
+//    commands, and instead it would just be a global queue, or something...
+//    it is a little weird since commands are not just consumed in order...
+//  - this will clean up the various different ways that codepaths
+//    parameterize commands.
+// [ ] frontend entities vs. engine entities
+//  - currently, the engine has entities like "watch", and the frontend
+//    has entities like "windows", "panels", and "views".
+//  - because "watch" entities ideally have a hierarchical relationship
+//    with windows, panels, and views (enabling things like drag/drop
+//    from watch window -> tab, or tab -> watch window, trivially), it
+//    would be much better if all entities could collapse into engine
+//    entities.
+//  - now, the frontend requires various specialized resources for things
+//    like windows, so what I am thinking is that the engine just controls
+//    all of the stateful windows/panel/view/watch mechanisms, and then
+//    the frontend pure-functionally queries stuff like os/r handles
+//    on-demand, and then prunes them, immediate-mode cache style.
+// [ ] command params -> d_regs
+//  - currently there are two almost-identical concepts relating to commands:
+//    the parameters struct, and D_Regs. D_Regs is a registers struct which
+//    is used to manage a stack of contextual information in various debugger
+//    codepaths. it is used so that codepaths can register information they
+//    know about, without passing it down to everyone explicitly - but those
+//    later codepaths can still pass that information along. e.g. a window
+//    calls into a watch window, watch window calls into visualizer, visualizer
+//    pushes command, which needs to pass which window it occurred on along.
+//  - i think D_Regs needs to expand a bit in order to encompass all of the
+//    things that the command parameters were being used for, but at that point
+//    commands can just be a spec * regs, and then the push-command API can
+//    just have ways of overriding regs values explicitly, when the codepath
+//    needs to be opinionated about which things are affected by which commands
 //
 // [ ] transient view timeout releasing
 //
@@ -431,28 +433,28 @@
 //      against stopper thread's
 //
 // [x] PDB files distributed with the build are not found by DbgHelp!!!
-// [x] Jai compiler debugging crash
-//
-//- 2024/8/29
+// [x] Jai compiler debugging crash
+//
+//- 2024/8/29
 //
 // [x] fix HRESULTs
 // [x] fix escape char literals
 // [x] eval: indexing into string literals
 // [x] fix incorrectly consuming keyboard inputs, preventing fallback-to-filtering, when
-//     selecting null selection in watch views
+//     selecting null selection in watch views
 // [x] ui_next_event(...), built-in focus filtering, no need to manually check
-//     if(ui_is_focus_active())
+//     if(ui_is_focus_active())
 //  [x] Theme window should include font scaling. I was able to find the
 //      command for increasing the font scale, but I imagine most people
-//      wouldn't think to look there.
+//      wouldn't think to look there.
 // [x] n-row table selection, in watch window & other UIs, multi-selection
 //     ctrl+C
-// [x] target/breakpoint/watch-pin reordering
-// [x] move breakpoints to being a global thing, not nested to particular files
+// [x] target/breakpoint/watch-pin reordering
+// [x] move breakpoints to being a global thing, not nested to particular files
 // [x] EVAL SPACES - each rdi gets an rdi space, rdi space is passed to
-// memory reads & so on, used to resolve to value space; REPLACES "mode"
+// memory reads & so on, used to resolve to value space; REPLACES "mode"
 // [x] fix selecting hover eval, then hover eval disappearing, causing
-//     busted focus, until a new hover eval is opened
+//     busted focus, until a new hover eval is opened
 //  [x] `text[:lang]` - interpret memory as text, in lang `lang`
 //  [x] `disasm:arch` - interpret memory as machine code for isa `arch`
 //  [x] `memory` - view memory in usual memory hex-editor view
@@ -461,21 +463,21 @@
 //  view, or memory view will simply be specializations of the general purpose
 //  viz system.
 //  [x] view rule hook for standalone visualization ui, granted its own
-//      tab
+//      tab
 //  [x] collapse frontend visualization systems - source view, disasm view,
-//      callstack, modules, scheduler, should *all* be flavors of watch view
-// [x] globally disable/configure bp/ip lines in source view
+//      callstack, modules, scheduler, should *all* be flavors of watch view
+// [x] globally disable/configure bp/ip lines in source view
 // [x] @cleanup naming pass over eval visualization part of the frontend,
-//     "blocks" vs. "canvas" vs. "expansion" - etc.
+//     "blocks" vs. "canvas" vs. "expansion" - etc.
 // [x] @cleanup collapse DF_CfgNodes into just being MD trees, find another way
-//     to encode config source - don't need it at every node
+//     to encode config source - don't need it at every node
 // [x] @cleanup in the frontend, we are starting to have to pass down "DF_Window"
 //     everywhere, because of per-window parameters (e.g. font rendering settings).
 //     this is really better solved by implicit thread-local parameters, similar to
 //     interaction registers, so that one window can "pick" all of the implicit
-//     parameters, and then 99% of the UI code does not have to care.
+//     parameters, and then 99% of the UI code does not have to care.
 // [x] @cleanup simplification pass over eval visualization pipeline & types,
-//     including view rule hooks
+//     including view rule hooks
 
 #ifndef RADDBG_H
 #define RADDBG_H