[JohnCampionJr]

Three small opt-in options, for parity with Ghostty's enquiry-response, osc-color-report-format and vt-kam-allowed. Each feature is its own commit, and review fixes follow as separate commits. Every default keeps today's behaviour, including DECRQM reporting KAM as xterm and esctest expect.

TerminalOptions.EnquiryResponse (ENQ answerback)

HandleExecute dropped ENQ (0x05). When this string is non-empty, ENQ replies with it. The reply is sent through RaiseInputData, not RaiseDataReceived, because the answerback is the user's literal string: the S8C1T converter would otherwise rewrite a leading ESC in it as one of the terminal's own reports. The case widens the execute switch's jump table, so LF, CR and BS pay no extra compare.

TerminalOptions.ColorReportFormat (None, EightBit, SixteenBit; default SixteenBit)

Every OSC colour reply (OSC 4 ?, the OSC 4/5 special colours, OSC 10/11/12) now goes through one ReplyColor helper:

• SixteenBit replies with rgb:rrrr/gggg/bbbb, as before.
• EightBit replies with rgb:rr/gg/bb.
• None sends no reply.

Only an explicit None is silent. A value outside the enum falls back to the sixteen-bit default.

TerminalOptions.KeyboardActionModeAllowed (default false) and Terminal.KeyboardLocked

KAM (ANSI mode 2) used to be recorded but never acted on.

• Always stored and reported. SM 2 and RM 2 set and reset mode 2, and DECRQM reports it whatever the option says, as xterm does and esctest's test_DECRQM_ANSI_KAM expects. This is unchanged from main.
• The option gates only the lock. KeyboardLocked is true exactly when mode 2 is set and KeyboardActionModeAllowed is on. While it is locked, GenerateKeyInput, GenerateCharInput and GenerateKittyKeyInput produce nothing, and Paste sends nothing. Hosts that encode their own input should check KeyboardLocked too.
• The option is read live. Turning it off unlocks at once, which gives the host a way out for a user that a crashed program left locked. Turning it on while mode 2 is set locks at once.
• Resetting: RM 2, RIS and DECSTR reset mode 2, and with it the lock.

A default terminal therefore can't be locked, but still reports KAM faithfully.

Terminal.KeyboardLockedChanged

A host showing a "keyboard locked" indicator no longer has to poll.

public event EventHandler<TerminalEvents.KeyboardLockedEventArgs>? KeyboardLockedChanged;   // args.Locked = the new KeyboardLocked

• Raised only when the effective value changes: through SM 2, RM 2, RIS or DECSTR, or the host flipping KeyboardActionModeAllowed. Nothing fires for SM 2 while the option is off, SM 2 when already locked, or a flip while mode 2 is reset.
• Threading: raised synchronously, after the new value is in place. For SM 2, RM 2, RIS and DECSTR that's the thread calling Write; for an option flip, the thread that set it.
• Conventions: it follows SynchronizedOutputChanged / SynchronizedOutputEventArgs. Option flips reach it through an internal hook installed like ScrollbackChanged, and Dispose clears both.

Tests

New EnquiryResponseTests, ColorReportFormatTests, KeyboardActionModeTests and KeyboardLockedChangedTests. KAM's case is kept in RequestModeTests.Stored_ansi_modes_toggle_and_report. The whole XTerm.NET.Tests project passes: 2386 passed, 1 skipped (the existing DA3 skip), 0 failed. Mutants that raise on every write of the mode or the option are each caught.

🤖 Generated with Claude Code

[tomlm]

Adds three opt-in options for Ghostty parity: EnquiryResponse (ENQ answerback), ColorReportFormat (OSC 4/5/10/11/12 reply width, or no reply), and KeyboardActionModeAllowed with a new Terminal.KeyboardLocked that the key, char, Kitty and paste paths check.

The ENQ and colour-format halves are sound. The KAM half changes default behaviour in a way that contradicts a test the repo deliberately added.

Medium

• KAM refused by default breaks esctest test_DECRQM_ANSI_KAM, and the test that pinned it was deleted rather than reconciled (InputHandler.StoredModes.cs:87). xterm, which the repo grades against, toggles and reports KAM. This PR changes the default path to Ghostty's behaviour without making it opt-in.

Doc comments

• Terminal.KeyboardLocked remarks say it is "only ever true when KeyboardActionModeAllowed is". TerminalOptions.KeyboardActionModeAllowed and the PR's own test Disallowing_after_a_lock_still_lets_RM_2_unlock both say the opposite (Terminal.cs:53).
• The RequestModeTests summary still justifies KAM being stored with "esctest toggles them and expects the toggle reported". That reason no longer holds for KAM, and the new line added under it contradicts it (RequestModeTests.cs:304).

Notes (checked, fine)

• ENQ dispatch: the parser routes 0x05 through OnExecute, so a registered execute handler runs first and a consuming one suppresses the reply. The TerminalOptions remark is accurate. Inside OSC and DCS payloads ENQ is not executed, and the tests cover both. Adding case 0x05 only moves the jump table's base from 7 to 5, so LF, CR and BS pay no extra compare, as the PR says.
• ENQ reply path: sending through RaiseInputData with no C1 conversion matches xterm's CASE_ENQ, which unparseputcs answer_back byte for byte. A null EnquiryResponse is handled by the is { Length: > 0 } pattern.
• Colour replies: every colour reply in InputHandler.Osc.cs now goes through ReplyColor. I grepped for rgb: and RaiseDataReceived and found no other colour-reply site. The OSC terminator is still mirrored. EightBit rgb:rr/gg/bb matches Ghostty's 8-bit format. CopyFrom copies all three new options.
• Unlocking: DECSTR unlocking KAM matches the VT510 DECSTR table. Both RIS and DECSTR reach ResetStoredModes, which now clears KeyboardLocked.
• Mouse input: GenerateMouseEvent and GenerateFocusEvent are not gated by KAM. That is correct, because KAM locks the keyboard only.
• Low: ColorSpec.Format(int, ColorReportFormat) returns null, meaning no reply, for any out-of-range enum value as well as None. A host that casts a bad int gets silence rather than an error.
• No new hot-path cost. TrySetStoredMode and the input-generation guards sit off the parse and print paths.

[tomlm]

Medium: refusing SM 2 by default regresses DECRQM conformance against xterm and esctest, and the test that encoded it was removed rather than reconciled.

With the default options, CSI 2 h followed by CSI 2 $ p now answers CSI 2;2 $ y. Before this PR it answered CSI 2;1 $ y. esctest2 decrqm.py:

def test_DECRQM_ANSI_KAM(self):
    self.doModifiableAnsiTest(esccmd.KAM)
...
  esccmd.SM(mode)
  AssertEQ(self.requestAnsiMode(mode), [mode, 1])

That now fails on a default terminal. xterm, the grading key elsewhere in this repo (see the DECARM and DECKPM comments in this file), sets MODE_KAM on SM 2 and reports it through DECRQM. RequestModeTests.Stored_ansi_modes_toggle_and_report had [InlineData(2)] precisely because aca3941 made KAM reportable for esctest. This PR deletes that case instead of keeping it green. CLAUDE.md lists this pattern under "things that have bitten twice": check whether an existing test already encodes the behaviour.

The safety goal does not require lying to DECRQM. The pre-PR behaviour was "stored and reported, not acted on", and that is what a disallowed KAM can keep doing:

if (!isPrivate && mode == 2)
    _terminal.KeyboardLocked = value && _terminal.Options.KeyboardActionModeAllowed;
table[mode] = value;

Done that way, a default terminal still cannot be locked, esctest stays green, and [InlineData(2)] can go back into the theory. If Ghostty's "report reset" is the deliberate choice, say so in the PR body. It is a user-visible change to the default path, not an opt-in.

[JohnCampionJr]

Agreed, fixed in c4184b5. SM 2 always stores and reports, as xterm does. KeyboardLocked is your expression, but read live: mode 2 is set AND KeyboardActionModeAllowed is on.

• A default terminal still can't be locked.
• Because it's live, turning the option off unlocks at once, which is the host's way out for a user that a dead program left locked.
• Turning the option on while mode 2 is set locks at once.

Both are documented and tested. [InlineData(2)] is restored in Stored_ansi_modes_toggle_and_report.

[tomlm]

Doc: this remark contradicts the option's own documentation and the PR's test.

KeyboardLocked can be true while KeyboardActionModeAllowed is false. TerminalOptions.KeyboardActionModeAllowed says "Turning this off does not unlock a keyboard already locked". KeyboardActionModeTests.Disallowing_after_a_lock_still_lets_RM_2_unlock asserts exactly that state: Options.KeyboardActionModeAllowed = false; Assert.True(terminal.KeyboardLocked);.

Suggest: "Only SM 2 sets it, and SM 2 is refused unless KeyboardActionModeAllowed is on at the time. Turning the option off later does not clear an existing lock. RM 2, RIS and DECSTR clear it."

[JohnCampionJr]

Rewritten in c4184b5:

• KeyboardLocked is true exactly when mode 2 is set and the option is on.
• DECRQM reports mode 2 whatever the option says.
• Turning the option off unlocks; turning it on with mode 2 set locks.
• RM 2, RIS and DECSTR reset it.

The contradicting test is replaced by Turning_the_option_off_unlocks_at_once_and_mode_2_stays_reported.

[tomlm]

Doc: the summary's first two lines still give esctest as the reason KAM is stored and toggled. This PR makes that untrue by default, and the added third line contradicts them.

Either drop KAM from the first sentence and state why it now diverges from esctest's test_DECRQM_ANSI_KAM, or keep KAM reportable when disallowed (see the comment on InputHandler.StoredModes.cs:87) and put [InlineData(2)] back.

[JohnCampionJr]

Fixed in c4184b5. KAM is reportable again, so the esctest reason holds for all three modes. [InlineData(2)] is back, and the added line now says KAM is reported whether or not the host lets it lock, pointing to KeyboardActionModeTests.

[JohnCampionJr]

Thanks. All taken in c4184b5:

• KAM is now always stored and reported, and KeyboardActionModeAllowed gates only the lock. That restores esctest's test_DECRQM_ANSI_KAM and [InlineData(2)].
• On the Low: only an explicit ColorReportFormat.None is silent now. An out-of-range value falls back to the sixteen-bit default, with a test.
• XTerm.NET.Tests: 2370 passed, 1 skipped (DA3), 0 failed.

I've updated the PR description to match.

[JohnCampionJr]

One addition since your review, in c0a37f6: Terminal.KeyboardLockedChanged, so a host can show a "keyboard locked" indicator without polling. It fires only when KeyboardLocked actually moves, whether through SM 2, RM 2, RIS, DECSTR or a flip of KeyboardActionModeAllowed. It's modelled on SynchronizedOutputChanged, and Dispose clears it.

The earlier commits are unchanged in content. Their messages were reworded, so the hashes in the replies above now read c4184b5 and friends.

The description has a new section on it. XTerm.NET.Tests: 2386 passed, 1 skipped, 0 failed.