textual-debugger 0.1.1__tar.gz → 0.1.3__tar.gz

{textual_debugger-0.1.1 → textual_debugger-0.1.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: textual-debugger
-Version: 0.1.1
+Version: 0.1.3
 Summary: A TUI Python debugger based on textual and debugpy
 Author-email: Al Danial <al.danial@gmail.com>
 License: textual-debugger is licensed to you under the MIT/X Consortium license:
@@ -88,9 +88,9 @@ It specifically supports modules
     - `threading` (with a thread inspector)
     - `multiprocessing` / `concurrent.futures` (with automatic child process attachment and a process inspector)
 
-- supports remote attachment to any debugpy-enabled Python program
+- supports remote attachment to debugpy-enabled Python programs
 
-- includes a JSON-RPC server mode for programmatic debug control, making it suitable for
+- includes a JSON-RPC server mode that enables programmatic debug control, making it suitable for
 automated, headless debugging workflows and AI-assisted debugging
 
 - can spawn the debuggee in an external terminal to enable debugging TUI applications
@@ -164,14 +164,16 @@ tdb my_program.py
 # debug with arguments
 tdb my_program.py arg1 arg2
 
-# add breakpoints at lines 20 and 35 of `my_program.py` and line 14 of `module.py`
+# add breakpoints at lines 20 and 35 of `my_program.py` and line 14
+# of `module.py` (when -k is given, --no-stop-on-entry is set and the
+# program runs to the first breakpoint)
 tdb -k 20 -k 35 -k module.py:14 my_program.py arg1 arg2
 
 # use a specific virtualenv
 tdb --python /path/to/venv/bin/python my_program.py
 
 # step into, or stop at tracebacks in library code
-tdb --no-just-my-code /path/to/venv/bin/python my_program.py
+tdb --no-just-my-code --python /path/to/venv/bin/python my_program.py
 
 # run until first breakpoint or exit
 tdb --no-stop-on-entry my_program.py
@@ -180,10 +182,20 @@ tdb --no-stop-on-entry my_program.py
 tdb --terminal xterm my_program.py
 
 # attach to a remote Python program that has a debugpy server on port 5678
-tdb -r remotehost:5678 my_program.py
+# (source code is automatically downloaded from the remote host)
+tdb -r remotehost:5678
 
-# prevent `argparse` confusion by separating `tdb` switches from
-# the debuggee switches by prefixing the debuggee with `--`
+# attach to a remote Python program that has a debugpy server on port 5678
+# and set a breakpoint where tdb and the remote program have the same
+# source code layout
+tdb -r remotehost:5678  -k my_program.py:42
+
+# attach to a remote Python program that has a debugpy server on port 5678
+# and set a breakpoint where code on the local host is at a different location
+# than code on the remote host
+tdb -r remotehost:5678 --local-root /my/code/dir --remote-root /app -k my_program.py:42
+
+# separate tdb arguments from debuggee arguments with `--` 
 tdb --python /path/to/venv/bin/python -- my_program.py -k 17 --max 23.3
 ```
 
@@ -197,7 +209,7 @@ python -m tdb my_program.py
 
 ```
 ┌─ Header ──────────────────────────────────────────────┐
-├─ Menu Bar (File | Configure | Help) ──────────────────┤
+├─ Menu Bar (File / Configure / Help)───────────────────┤
 │                           │                           │
 │   Code View               │  Console View (stdout)    │
 │   (source + breakpoints)  ├───────────────────────────┤
@@ -242,7 +254,7 @@ A cursor line (blue) tracks your position; the current execution line is highlig
 | Key | Menu |
 |-----|------|
 | `Alt+F` | File (open a different script to debug) |
-| `Alt+C` | Configure (Color Theme, Keybindings) |
+| `Alt+C` | Configure (Color Theme, Keybindings, Step Mode) |
 | `Alt+T` | Threads |
 | `Alt+P` | Processes |
 | `Alt+A` | Async Tasks |
@@ -268,7 +280,7 @@ Switch from Navigate back to Debug mode with `Escape`.
 
 > **Note:** Many terminals send the byte sequence `ESC+f` for `Alt+F`, which Textual's
 ANSI parser rewrites to `Ctrl+Right` (the readline "forward-word" convention).
-`tdb` binds both so `Alt+F` works as expected regardless.
+`tdb` binds both so `Alt+F` works as expected.
 
 ### Debugging Controls
 
@@ -277,21 +289,42 @@ those for gdb/pdb, with some aliases and extras thrown in for convenience.
 
 | Key | Action |
 |-----|--------|
-| `n` | Step over (next line) |
+| `n` | Step over (next statement) |
 | `s` | Step into function call |
 | `o` / `f` / `r` | Step out of current function (also aliased as "finish" and "return") |
 | `c` | Continue execution |
 | `p` | Pause a running program |
 | `t` | Run to cursor position |
 | `u` / `d` | Navigate stack up (caller) / down (callee) |
+| `j` / `k` | Move cursor down / up (with count: `5j`, `10k`) |
+| `G` | Go to last line (with count: `42G` jumps to line 42) |
+| `e` | Re-display the last error (traceback) |
 | `R` | Restart the debug session |
-| `Ctrl+Q` | Quit |
+| `q q` | Quit |
+| `Ctrl+q` | Quit |
 
 > **Note:** `f` ("finish") and `r` ("return") are both aliases for step-out. DAP's only
 "exit-a-function" primitive is `stepOut`, which runs the rest of the current function
 normally and stops at the return point. A true gdb-style immediate-return (skipping
 remaining code in the function without executing side effects) is not supported by DAP/debugpy.
 
+**Step granularity (statement vs. line):** by default, `n` (step over) and `s` (step into)
+treat a multi-line source statement as a single step. For example, stepping over
+
+```python
+results = await asyncio.gather(
+    fetch(1, 2),
+    fetch(2, 1),
+    fetch(3, 3),
+)
+print(results)   # next stop lands here, not on each sub-line above
+```
+
+lands on `print(results)`, not on each interior sub-line of the `gather` call. Switch to
+**Line** mode (Configure > Step Mode) to get debugpy's native per-line behavior, which
+stops on each physical line--useful for inspecting how a complex expression is built up.
+The choice is saved to `~/.config/tdb/config.json`.
+
 ### Breakpoints
 
 Click the gutter in the Code View to toggle a breakpoint, or press `b` in Debug mode.
@@ -316,6 +349,11 @@ The Variable View shows a tree of scopes (Locals, Globals) with all variables in
 frame. Expand nodes to drill into complex objects.  Children are loaded lazily on demand.
 Variable values can be changed in the Evaluate Console.
 
+Double-click a variable, or highlight the variable with the text cursor in
+the Variables View and press `Enter`
+to display that variable in a modal.  This simplifies inspection of
+large or deeply nested data structures.
+
 ### Call Stack
 
 The Stack View shows the full call stack. Click a frame to navigate to its source
@@ -323,7 +361,8 @@ location and inspect its variables.
 
 ### Evaluate Console
 
-A REPL at the bottom-left evaluates expressions in the current scope:
+A read-evaluate-print loop (REPL) at the bottom left permits
+interactive evaluation of expressions in the current scope:
 
 ```
 >>> len(items)
@@ -349,8 +388,11 @@ The Console View captures stdout (normal text) and stderr (red text) from the de
 in real time.
 
 If your program prints a lot, or prompts for input, or uses colors or
-terminal control codes, consider running it in an external terminal
-with `--terminal` for the best experience.
+terminal control codes, run the program in an external terminal
+with `--terminal` for a better experience.
+The `--terminal` switch requires a graphical environment and a compatible
+terminal emulator.
+
 
 ### Crash Detection
 
@@ -360,6 +402,9 @@ When the debuggee raises an unhandled exception, `tdb`:
 3. Populates the Stack View with the exception's call stack
 4. Lets you press `R` to restart or `Escape` to dismiss
 
+> Note:  after dismissing the traceback modal, you
+> can display it again by hitting `e` when focus is in the Code View.
+
 ### Post-Mortem Exception Hook
 
 You can have `tdb` pop open automatically when *any* Python program crashes without the
@@ -368,7 +413,6 @@ need to launch through `tdb` up front. Install the hook once at the top of your
 ```python
 import sys
 import tdb
-
 sys.excepthook = tdb.exception_hook
 ```
 
@@ -386,11 +430,11 @@ In post-mortem mode you can:
 - Read the full traceback (including chained `cause`/`context` exceptions) in the Console View
 - Jump around the source with the full Code View (syntax highlighting, goto-line, etc.)
 
-Stepping, `continue`, breakpoints, restart, and Evaluate are disabled. The original
-interpreter is gone, the view is a frozen snapshot. Press `q` to exit.
+Stepping, continue, breakpoints, restart, and the Evaluate View are disabled. The original
+interpreter is gone since the view is a frozen snapshot. Press `q` to exit.
 
 The hook is a no-op when stdin/stdout aren't a tty (e.g. when your program is piped or
-run from cron), so it's safe to leave installed in production-style code. Snapshots are
+run from cron), so it is safe to leave installed in production code. Snapshots are
 written to a temp file that is deleted as soon as `tdb` exits.
 
 Snapshot depth / breadth is capped (5 levels, 50 children per container) to keep the
@@ -401,7 +445,6 @@ memoization.
 
 `tdb` has an improved implemenation of the standard `breakpoint()` function (or equivalently,
 `pdb.set_trace()`) used to pause at a specific line to inspect, then
-here=
 continuing--use `tdb.breakpoint()`:
 
 ```python
@@ -424,7 +467,7 @@ spawns `python -m tdb -r <port>` as a subprocess so the TUI takes over the termi
 and pauses the calling thread at the line that called `tdb.breakpoint()` (the hook
 auto-steps out of its own helper so you land in your own frame, not inside
 `breakpoint_hook.py`). Stepping (`n`/`s`/`o`), `continue`, and setting/removing breakpoints
-all work normally; quitting `tdb` (`Ctrl+Q`) detaches without killing the program, and
+all work normally; quitting `tdb` (`Ctrl+q`) detaches without killing the program, and
 debugpy auto-resumes any threads still paused.
 
 This differs from `tdb.exception_hook` in one way:
@@ -437,6 +480,12 @@ drive the user's program forward.
 As with `exception_hook`, the call is a no-op when stdin/stdout aren't a tty, so it's
 safe to leave in code paths that sometimes run headless.
 
+Quitting `tdb` while paused in a `tdb.breakpoint()` session detaches the debugger and
+lets the program continue running normally.
+This behavior matches hitting `c` while in a conventional (that is, the Python
+standard library's) `breakpoint()` session.
+If you want to kill the program instead, use `Ctrl+c` in the terminal running the debuggee.
+
 ### Async Task Inspector
 
 For programs using `asyncio`, the menu bar shows an **Async Tasks (N)** label with the count of
@@ -446,13 +495,17 @@ active tasks (updated each time the program stops). Click it to open a full-scre
   primitive (`Lock.acquire`, `Queue.get`, `asyncio.sleep`, …), and coroutine
 - **Right pane**: detail view with full stack trace and an expandable variable tree (same
 as the main Variables View) for the selected task
-- Press `g` to switch the right pane to the **wait graph** — a tree showing each blocked
+- Press `g` to switch the right pane to the **wait graph** which is a tree showing
+  each blocked
   task, the asyncio primitive it's parked on, and the task(s) holding that primitive.
   Cycles (deadlocks) are highlighted in red both in the task table and as a "Deadlock
   cycles" section at the top of the graph. Selecting a node in the tree highlights the
   corresponding task in the table.
 - Navigate with arrow keys; press `r` to refresh, `Escape` to close
 
+> Note:  Async task relationships may be directed acyclic graphs (DAGs) rather than trees
+> but I don't know of a way to visualize DAGs in textual.
+
 RPC equivalents:
 
 ```bash
@@ -564,6 +617,36 @@ All debugging features (breakpoints, stepping, variable inspection, threads, pro
 async tasks) work in remote attach mode. The Code View automatically navigates to the
 source file when the program stops.
 
+**Mapping remote paths to local copies (`--local-root` / `--remote-root`):** when the
+debuggee lives on another machine, or in a container, or simply in a different directory
+on the same machine, the source paths it reports (and the paths it expects breakpoints
+to refer to) won't match anything on the `tdb` host. To bridge that gap, give `tdb` one
+or more `--local-root` / `--remote-root` pairs. Each `--local-root` points at a local
+directory containing a copy of the code; each `--remote-root` is the corresponding path
+on the debuggee. The two flags must be supplied in equal numbers and are paired in CLI
+order via `zip()`, so the first `--local-root` matches the first `--remote-root`, the
+second matches the second, and so on. `debugpy` then translates paths bidirectionally:
+breakpoints set on a local file land on the matching remote file, and source paths
+returned in stopped-events / stack-traces are rewritten back to the local copy so the
+Code View loads directly from disk (no DAP `source` round-trip needed).
+
+These flags are required whenever you want to set a `-k` breakpoint against a remote
+debuggee whose code lives at a different path than your local copy. For example, if the
+remote runs `program.py` at `/path/to/code/program.py` and your local copy is at
+`/local/project/code/program.py`, set a breakpoint at line 321 with:
+
+```bash
+tdb -r RHOST:15678 \
+    --local-root /local/project/code \
+    --remote-root /path/to/code \
+    -k program.py:321
+```
+
+With `--local-root` set, a relative `-k FILE:LINE` is resolved by searching each
+`--local-root` directory in CLI order (first match wins); absolute paths still work as
+before. Multiple pairs can be supplied to mirror multiple source trees (e.g. an
+application directory and a shared library directory) in one invocation.
+
 ### External Terminal Support
 
 Some Python programs, notably text user interfaces, use terminal control
@@ -691,22 +774,25 @@ Each is JSON with `event`, `data`, and `timestamp` fields.
 ## CLI Reference
 
 ```
-usage: tdb [-h] [-v/--version] [-r [HOST:]PORT] [--cwd CWD] [--no-stop-on-entry]
-           [--no-just-my-code] [--no-subprocess] [--python PYTHON]
-           [-d/--doc] [--doc-text] [--keybindings {default,vim,emacs}]
+usage: tdb [-h] [-v] [-r [HOST:]PORT] [--cwd CWD] [--no-stop-on-entry]
+           [--no-just-my-code] [--no-subprocess] [--python PYTHON] [--pv]
+           [--keybindings {default,vim,emacs}]
            [--terminal {xterm,konsole,gnome-terminal,ghostty,kitty,iterm2,warp,wezterm,terminator}]
-           [--server] [--headless] [-k FILE:LINE|LINE] [--server-port SERVER_PORT]
+           [--local-root PATH] [--remote-root PATH]
+           [--server] [--headless] [-k FILE:LINE|LINE] [--server-port SERVER_PORT] [-d] [--doc-text]
            [program] [args ...]
-
 ```
 
 | Flag | Description |
 |------|-------------|
 | `-r HOST:PORT` | Attach to a remote debugpy server |
-| `-k`, `--breakpoint FILE:LINE|LINE` | Set a breakpoint (may be repeated) |
-| `--no-stop-on-entry` | Do not pause at the first line (default: stop on entry) |
+| `--local-root PATH` | Local directory containing a copy of remote code (repeat to mirror multiple trees). Pair with `--remote-root`; counts must match. Required when `-k` sets a breakpoint against a remote debuggee whose code lives at a different path. |
+| `--remote-root PATH` | Remote directory matched to `--local-root` (same CLI position via `zip()`). |
+| `-k`, `--breakpoint FILE:LINE|LINE` | Set a breakpoint (may be repeated). Passing `-k` implies `--no-stop-on-entry` so the program runs straight to the first breakpoint. |
+| `--no-stop-on-entry` | Do not pause at the first line (default: stop on entry; automatic when `-k` is given) |
 | `--cwd DIR` | Working directory for the debuggee |
 | `--python PATH` | Python interpreter for the debuggee |
+| `--pv` | Shorthand for --python .venv/bin/python |
 | `--no-just-my-code` | Step into stdlib/site-packages code instead of skipping it
   (default: skipped). On uncaught exceptions, the crash modal always shows the full traceback
   including library frames, regardless of this flag. |
@@ -726,12 +812,25 @@ On Windows, it uses `%APPDATA%\tdb\`.
 
 | File | Contents |
 |------|----------|
-| `config.json` | User preferences (keybinding scheme) |
+| `config.json` | User preferences (keybinding scheme, color theme, step mode) |
 | `breakpoints.json` | Breakpoints from previous sessions, keyed by project directory |
 
 Breakpoints are saved on exit and restored when debugging a program in the same
 directory. Each project's breakpoints are independent.
 
+**Step mode** (`step_mode` in `config.json`) controls how `n` (step over) and `s` (step
+into) handle multi-line source statements:
+
+| Value | Behavior |
+|-------|----------|
+| `"statement"` (default) | A multi-line statement (e.g. a `gather(...)` call spanning five lines) is one step. The debugger keeps issuing DAP steps until execution leaves the statement, then stops on the next logical line. |
+| `"line"` | debugpy's native per-line behavior (stops on every physical line, including each interior sub-line of a multi-line expression)|
+
+Change it from the menu (**Configure > Step Mode**); the choice is saved immediately and
+applies to all future sessions. Breakpoint hits, exceptions, and pauses always interrupt
+a statement step, so a breakpoint set on a sub-line of a multi-line expression still
+fires as expected.
+
 ## Tech Stack
 
 - [textual](https://github.com/Textualize/textual) : TUI framework