feat(events): lvt-key modifier matching (Mod+Enter)

[adnaan]

lvt-key modifier matching (Mod/Meta/Ctrl/Shift/Alt + key)

lvt-key matched event.key with exact equality, so a chord like Cmd/Ctrl+Enter was indistinguishable from a plain Enter. That makes a common pattern impossible to express: submit on Cmd+Enter while the textarea keeps plain Enter for newlines.

What changed

A shared keyFilterMatches(e, filter) helper, used by both keydown/keyup match sites (delegated element bindings + window bindings):

• Bare filter ("Enter", "Escape", "j", "+") → matches event.key verbatim, regardless of modifiers. Existing bindings are byte-for-byte unchanged (the back-compat path).
• Combo ("+"-joined) → final segment is the key; leading segments are required modifiers:
  • Mod = metaKey || ctrlKey (the platform command key: ⌘ on macOS, Ctrl elsewhere)
  • Meta/Cmd, Ctrl/Control, Shift, Alt/Option
  • e.g. lvt-key="Mod+Enter", lvt-key="Shift+ArrowDown". Lenient about extra modifiers; an unknown token never matches.
• A combo match calls preventDefault() so the chord isn't also typed into the focused field (Mod+Enter won't insert a newline).

Safety

lvt-key is the event filter only; node identity uses data-lvt-key, so the new values don't affect morphdom reconciliation. Back-compat is covered by an explicit test (a bare "Enter" filter still matches a modified Enter).

Tests

10 new (8 unit on keyFilterMatches + 2 integration through the delegator, incl. preventDefault and the plain-Enter-doesn't-fire case). Full suite green (772 passed).

Motivation: consumed by livetemplate/prereview to add Cmd/Ctrl+Enter-to-save in its comment composer.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ey41dRwDpRgLtVHZjhYLKt

[claude]

Review

Overall this is well-structured and the test coverage is solid. One behavioural concern and one minor gap.

preventDefault() is unconditional for all combo matches

The PR intentionally calls preventDefault() on every matched combo so Mod+Enter does not also insert a newline. That makes sense for that specific case, but the same logic fires for combos like Shift+ArrowDown or Alt+ArrowLeft, where developers may want the default browser action to still happen (text selection, history navigation, etc.) alongside the custom handler. The risk is that lvt-key="Shift+ArrowDown" silently loses text-selection behaviour in adjacent focused fields. Worth documenting or offering an opt-out attribute like lvt-key-prevent="false".

Mod++ is unrepresentable

"Mod++".split("+") produces ["Mod", "", ""], so key = "" never matches. The docs acknowledge "+" only works as a bare filter, but it may be surprising that Shift++ cannot be expressed. Low priority, but worth documenting.

Everything else looks good

Back-compat path (bare key verbatim match, no preventDefault) is correct and tested. Both keydown match sites are updated consistently. The default: return { matched: false, combo: true } path for unknown modifiers is safe since no preventDefault is called on a non-match. mod.toLowerCase() for modifier names with a case-preserved key segment is the right call.