Editora 0.20.0 docs. You are reading an archived version, kept so links from that release keep working. Read the 0.21.0 docs →

Running & debugging

Running files

You can run compact Java and Python files with language services disabled. A green ▶ appears in the gutter of a runnable file:

• a Java compact source file (JEP 512, a .java with a top-level void main) or an extensionless Java file with a java --source 25+ shebang,
• a Python script (the ▶ sits on the if __name__ == "__main__" guard), or
• a shell script (only when LSP is turned on and its Bash server is enabled).

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.

A clicked Java frame in the Run, Test or Build console is resolved by the language server, so a frame inside a dependency or the JDK opens its source instead of reporting “not found”. Frames in your own code open as usual, and filename matching handles anything the server can’t place, plus every non-Java trace.

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 or newer. Editora uses the selected Default JDK when one is configured, or java on your PATH, and checks that exact launcher before running. An extensionless shebang can request a newer source release.

For Maven projects, Settings → Languages & Tools → Build Tools → Default JDK selects the toolchain used by Run, Debug, Maven classpath resolution, Maven tasks, and before-launch steps. Installed JDKs are discovered from the usual platform locations and common version managers. A run configuration’s JDK field can inherit that choice or override it for one configuration. The Default JDK also applies to standalone Java Run and Debug.

Running a project’s main class

Beyond single files, Run: Run Main Class… (run.mainClass) and Debug: Debug Main Class… (debug.mainClass) pick any main class in the active file’s Maven or Gradle project and run it in the Run console or debug it with breakpoints. A green ▶ also appears in the gutter next to every public static void main, and the editor right-click menu offers Run ‘….main()’ and Debug ‘….main()’.

There are two paths under that, picked automatically:

• With the Java language server set up, Editora asks it for the project’s main classes and resolved classpath. This is the fast, project-wide path, and it is the only one that can debug.
• Without it, plain Run falls back to the build tool: Maven resolves the classpath (mvn compile dependency:build-classpath) and runs the file’s main, and Gradle delegates to its run task, or bootRun in a Spring Boot project. In a multi-module Maven build the fallback runs from the reactor root with -pl <module> -am, so a submodule that depends on an uninstalled sibling still runs.

Run configurations

A run configuration saves how something is launched: a name, what to launch, program arguments, VM arguments, environment variables (KEY=value, quoting values that contain spaces), an optional JDK override, and a working directory.

What a configuration can launch

Pick a Type in the project/session-scoped Run Configurations window:

The form enables only the fields the selected type uses. A Java main class has no Script / target field; a Python, shell, Make or NPM configuration has no Main class, Module, VM arguments or JDK. A field that is disabled keeps its value, so switching the type and back loses nothing.

Script and make configurations need no project and no language server. Debugging a run configuration remains Java-only, and says so rather than reporting a confusing Java error.

The toolbar selector

The toolbar carries a configuration dropdown with Run, Debug and Stop beside it; your choice is remembered across restarts. The dropdown ends with Edit Configurations…, which opens the separate Run Configurations window with the configuration you had selected already picked out. The same window is available as Run: Edit Run Configurations… (run.editConfigs).

Starting a file or configuration always opens and focuses the Run tool window. If that process is already active, Run brings its existing console back instead of hiding the useful output behind a busy message.

The group only appears where you could launch something: with a project open and a Maven, Gradle, npm, Cargo or Go build file inside it, or a makefile at its root; with no project open, any detected build does. Anything you have already saved keeps the group visible regardless, because a configuration only needs a main method and a plain Java folder can hold one. The palette commands work anywhere either way.

Each configuration also becomes a real command, so it appears in the palette by name and can be given its own keyboard shortcut in Settings → Keymaps, the same way saved macros and external tools work.

A step before the launch

A configuration can name a command to run first, such as a build or a codegen step. A non-zero exit aborts the launch, so a stale binary is never run by accident.

Sharing them with your team

Export Configurations to Project writes them to .editora/run-configurations.json inside the project, where they can be committed alongside the project’s committed settings. Import merges them back by name, so importing twice doesn’t duplicate and a colleague’s edit updates a configuration rather than doubling it.

Creating and editing them

The Run Configurations window (run.editConfigs, or Edit Configurations… in the toolbar dropdown) is a master-detail editor for the list, and Run: Save Run Configuration… creates one from the palette; Run: Run Configuration… runs one and Run: Delete Run Configuration… removes one.

Add starts from the file you are looking at rather than a blank entry: it prefills the main class from the active Java file (or the one your Gradle build declares as mainClass, mainClass.set(…), or the legacy mainClassName), names the configuration after that class, and puts the cursor in whichever field still needs you. Adding twice from the same file gets you “App” and “App (2)” rather than two entries sharing a name.

Running an incomplete configuration opens its form at the field you need to fill in, rather than naming the problem and leaving you to find it. VM arguments and environment variables apply to both Run and Debug.

A saved configuration does not depend on which tab is in front: any open Java file in the project serves, and it reports an error only when there isn’t one.

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.

The keys are the Emacs keymap’s; the step commands are also buttons in the 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.

While a session runs, a breakpoint the debugger has not verified (its code is not loaded yet, or the line has no code) is drawn as a hollow ring, with the debugger’s explanation on hover. Every breakpoint is hollow from the start of the session until the debugger answers, and the markers return to normal when the session ends.

When the panel is wide enough, the call stack, variables, and console sit side by side; they stack when it is narrow. The call stack lists the innermost 1,000 frames when the adapter supports partial stacks. The console is cleared at each launch and kept after the session ends, and its right-click menu has Clear Console. Restart is disabled for a debugger attached to a test or build run (its tooltip says why); a session started with Debug → Attach can still be restarted.

Program input in the Debug console

A debugged Java program can read its standard input from the Debug console. The field does one of two things, and its prompt says which:

• While the program runs, Enter sends the line to the program (an empty line counts).
• While it is paused, Enter evaluates an expression.

End the input with Ctrl+D in the field, the console’s right-click menu, or Debug: End Program Input (EOF) (debug.endProgramInput).

In this mode Editora starts the Java program itself rather than leaving it to the debugger, and stops it on Stop, Restart, a new launch, a failed launch, or closing the window. The session ends when the program exits, after its last output, and the console reports the exit code. Lines written to stdout and stderr at almost the same moment can appear in either order.

It is on by default. The switch is under Settings → Debugging → Java (or Debug: Toggle Program Input in the Debug Console, debug.toggleProgramConsole) and takes effect at the next launch. Attached sessions, Python, and JavaScript are unaffected. It has not yet been confirmed on Windows.

Compact .java sources and extensionless Java --source 25+ shebang files can be debugged with breakpoints, stepping, and local variables. Editora maps breakpoints and stack frames to the original file and removes its temporary compiled files after the session. Java debugging needs the Java language server and debug adapter described below.

JUnit tests are debugged from their gutter icon or with Debug Test at Caret, including tests inside @Nested classes; see the test runner.

When the Debug panel has the keyboard (it shows an active-focus highlight), gdb-style single keys drive the session: n to step over, s to step into, f to finish (step out), and so on. Stepping keeps focus in the panel, so you can step repeatedly without your key presses landing in the editor. A fresh breakpoint hit while you’re editing still takes you to the code.

Debug via the build tool

Some applications are meant to be started by the build tool rather than by a bare java command. Debug: Debug via Build Tool (debug.viaBuild) launches the app under a suspended JVM through Gradle (run or bootRun with --debug-jvm) or, for a Spring Boot Maven project, spring-boot:run with a JDWP agent. Editora watches the build output for the JDWP banner and attaches the debugger when the app is listening. It complements Debug Main Class, which uses the language server; a plain Maven main has no uniform build-tool debug mechanism, so use Debug Main Class there.

Installing adapters

Adapters are not bundled. Three palette commands download each language’s adapter, together with its language server, into your config folder:

Editora does not install those runtimes for you.

To install an adapter by hand instead, the Editora repository has a helper script for each:

• Java: the Microsoft java-debug plugin (layered onto jdtls), scripts/install-java-debug.sh. If your jdtls distribution already bundles and loads java-debug itself (Homebrew’s does), Editora detects that and needs no second copy.
• Python: debugpy, scripts/install-debugpy.sh.
• JavaScript: vscode-js-debug, scripts/install-js-debug.sh.

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. A build task that would run a project’s own ./mvnw or ./gradlew asks you to trust the folder first.