Add an opt-in shortcut to format JavaScript code in the editor

Motivation

The interview editor currently provides several editing helpers, including:

• automatic indentation;
• bracket pairing;
• line-comment toggling;
• editor font and theme controls.

However, it does not provide a way to reformat code that has become difficult to read.

A shortcut such as Shift+Alt+F is familiar to candidates who use VS Code and other code editors. It could be useful when a candidate wants to reformat code after moving a block or making several indentation changes.

Concern about interview behavior

Automatic formatting may make the exercise easier than a real technical interview, where a formatter may not be available. It should therefore not be enabled implicitly for every candidate.

The feature should be opt-in, and the first version should be deliberately limited rather than attempting to support every language immediately.

Proposed first version

Start with JavaScript only.

A possible first version could:

• add an opt-in editor setting for formatting;
• format the current JavaScript buffer with Shift+Alt+F;
• avoid adding another toolbar button;
• leave Python, C, C++ and Java unsupported initially;
• preserve the current buffer if formatting fails;
• show a clear non-blocking error when the formatter cannot parse the code;
• keep the candidate's selection or place the caret at a predictable location after formatting;
• send the formatted result through the existing editor update path.

The setting could be disabled by default so that existing interview behavior does not change.

Expected behavior

When the formatting option is enabled and the candidate presses Shift+Alt+F in a JavaScript editor:

1. The current JavaScript code is formatted.
2. The editor content is updated as one normal editor change.
3. Syntax highlighting, line numbers and editor history remain synchronized.
4. The formatted code is used by the existing test runner.
5. If formatting fails, the original code remains unchanged and the candidate receives a visible error message.

When the option is disabled, pressing the shortcut should not format the code.

Acceptance criteria

• Formatting is disabled by default.
• The feature is available only for JavaScript in the first version.
• The shortcut is exposed through aria-keyshortcuts or equivalent accessible help.
• Formatting does not add a new toolbar button.
• Formatting failures do not replace or corrupt the candidate's code.
• The existing editor history can undo a formatting operation in one step.
• Syntax highlighting remains aligned after formatting.
• The line-number gutter is updated correctly.
• The formatted buffer is used by the existing JavaScript test runner.
• Python, C, C++ and Java behavior remains unchanged.
• The shortcut does not interfere with normal text input, browser shortcuts or the existing comment shortcut.
• The option's state is persisted if editor options are already persisted for the current workflow.

Current implementation

The editor is a native <textarea> with separate rendering layers for syntax highlighting and line numbers. Existing editor keyboard behavior is handled in:

• web/editor.js, which contains editing helpers and keyboard-related predicates;
• web/interview.js, which handles editor events, history, rendering and publishing;
• web/interview.html, which contains the editor controls;
• web/editor-options.js, which stores editor option state.

There is currently no language formatter integrated into the browser editor.

Alternatives considered

Support every language immediately

Supporting Python, C, C++ and Java would require different formatters, different parser behavior and a larger browser-side dependency footprint. It would also make failure behavior harder to keep consistent across languages.

Add a toolbar button

A button would make the feature easier to discover, but the editor toolbar already contains the language selector, restore control, font controls, theme control and Run tests button. A shortcut-only first version would avoid making the toolbar more crowded.

Format automatically on save or before running tests

Automatic formatting could modify the candidate's code without an explicit action and could make interview behavior less predictable. An explicit shortcut is less surprising.

Open questions

• Should the formatter run in the browser, or should formatting be delegated to another service?
• Is JavaScript-only an acceptable first boundary?
• Should the option be available in both Practice and Interview modes?
• Should formatting the entire buffer be the only supported operation, or should a selected range be formatted?
• Should formatting be allowed during a live interview, or only in Practice mode?
• Is an opt-in formatter consistent with the project's intended interview experience?