Reviewing files that changed from the base of the PR and between b407df3 and 57c7416.

• input.go (2 hunks)
• input_test.go (3 hunks)

input_test.go (3)

89-93: LGTM!

Comment formatting improvements enhance readability.

---

276-279: LGTM!

Comment formatting improvements.

---

552-561: Good test coverage for SS3 modifier formats.

The tests cover the key SS3 modifier formats: standard 1;mod, short form mod, and empty-prefix ;mod. This aligns well with the implementation in input.go.

input.go (2)

449-452: LGTM!

Resetting csiParams when entering SS3 state ensures clean parameter accumulation for SS3 sequences with modifiers.

---

506-527: Verify handling of unexpected SS3 parameter formats.

The modifier parsing logic at lines 519-525 handles specific formats (1;mod, ;mod, mod), but if a sequence has an unexpected first parameter (e.g., ESC O 2;5 P), no event is posted. This may be intentional to ignore non-conforming sequences, but could also silently drop valid user input from uncommon terminals.

Consider whether a fallback to emit the key with ModNone would be safer:

 			} else if parts := strings.Split(string(ip.csiParams), ";"); len(parts) >= 1 {
 				// SS3 with modifier (old style).  Note old terminfo would declare these as high
 				// numbered function keys, but we encode as modified since that's how they are entered.
 				if len(parts) >= 2 {
 					if m, err := strconv.Atoi(parts[1]); err == nil && (parts[0] == "1" || parts[0] == "") {
 						ip.post(NewEventKey(k, "", calcModifier(m)))
+					} else {
+						// Unrecognized format, emit key without modifiers
+						ip.post(NewEventKey(k, "", ModNone))
 					}
 				} else if m, err := strconv.Atoi(parts[0]); err == nil {
 					ip.post(NewEventKey(k, "", calcModifier(m)))
+				} else {
+					// Failed to parse modifier, emit key without modifiers
+					ip.post(NewEventKey(k, "", ModNone))
 				}
 			}

If the current behavior is intentional (ignoring non-conforming sequences), a brief comment would help clarify this design choice.

Reviewing files that changed from the base of the PR and between 57c7416 and 27832af.

• input.go (2 hunks)
• input_test.go (5 hunks)

• input.go

input_test.go (3)

89-93: Control-key coverage for 0x1B–0x1F looks correct

The added cases for ESC and 0x1C–0x1F (mapping to KeyEscape and KeyRune with ModCtrl) align with the documented NewEventKey behavior and nicely complete the control-key table.

---

276-279: Sequential input expectations match null-byte semantics

The updated expectations for the sequential inputs—especially treating 0x00 as KeyRune + " " + ModCtrl—are consistent with the earlier null-byte tests and ensure queue ordering is exercised.

---

443-459: for range 10 is valid Go syntax as of Go 1.22 and is perfectly acceptable in this codebase (which requires Go 1.24.0 per go.mod). No changes are needed.

Likely an incorrect or invalid review comment.