Running & debugging

Running files

With the LSP feature enabled, a green ▶ appears in the gutter of a runnable file:

Click the ▶, use the right-click Run File, or bind file.run (C-c r). Output streams to the Run tool window (M-9), which accepts stdin so console-style programs work, and stack-trace lines are clickable (Java, Python, and Node frames) to jump to the file and line.

Pass per-file program arguments with file.runWithArgs (remembered across runs and reused by the debugger), and repeat the last run with run.rerun. Running a Java file needs JDK 25 on your PATH; Editora preflights this and reports a clear message if it finds an older Java.

Debugging

Beta

Editora debugs Java, Python, and JavaScript (Node) through the Debug Adapter Protocol, with an IntelliJ-style Debug tool window (M-g d). Debugging is off by default; enable it in Settings → Debugging.

ActionCommandDefault key
Start / continuedebug.startC-c C-d d
Toggle breakpointdebug.toggleBreakpointC-c C-b
Pausedebug.pauseC-c C-d p
Run to cursordebug.runToCursorC-c C-d u
Jump to linedebug.jumpToLineC-c C-d j
Step over / into / outdebug.stepOver(Debug window)

The Debug window has a threads and call-stack view, a lazy variables tree with set-value, watches, and an evaluate console. While suspended, inline values appear after each line and hovering a variable shows its value. Breakpoints live in a leftmost gutter strip and are saved per project. Edit Breakpoint is a form for all three: a condition, a log message (which turns it into a logpoint that logs and never suspends), and an enabled toggle. Breakpoints in closed files are honored too.

Installing adapters

Adapters are user-installed, not bundled. Helper scripts in the Editora repo fetch each one:

The Settings → Debugging page shows a live found/not-found status for each.

For sending HTTP requests from .http files, see the HTTP client. For Maven, npm, Cargo, Go, and Gradle tasks, see Build tools.