Commit graph

2 commits

Author SHA1 Message Date
Vadim Peretokin
930ea5af5c
infrastructure: trim the comments left behind by two merged QA fixes (#9708)
#### Brief overview of PR changes/additions
- Comment-only. `git diff origin/development...HEAD` changes no
statement, expression or declaration - every added and removed line is a
comment. 238 comment lines become 98.
- Applies the house standard to the comments added by "fix: a trigger
that re-creates itself freezes Mudlet" (#9697) and "Fix user key
bindings on Ctrl+1 to Ctrl+9 and Ctrl+Tab" (#9703): no historical
passages, and the rest cut to what a reader cannot derive from the code.
- Corrects four claims that were wrong, two of them inherited from those
PRs: a fires-per-line measurement taken with a smaller budget than the
one that shipped, an over-general note on `shortcutInstalledFor()`, a
`KeyUnit::disableKey()` note that had the mechanism backwards, and a
test comment crediting the `isEmpty()` guard for a result it does not
produce.

#### Motivation for adding to Mudlet
Both PRs merged while their comment-reduction pass was still in flight,
so the trim never landed with them.

#### Other info (issues closed, discussion etc)
The gotchas worth keeping survive in shorter form: why the same-line
creation budget is counted per pass rather than sharing the
`feedTriggers()` depth counter, why permanent triggers get
`deactivate()` and not `setIsActive(false)`, why `mCleanupSet` rather
than the deactivation is what stops `enableTrigger()` resurrecting a
spent trigger, that `QShortcutMap` retries with consumed modifiers
stripped, and the `Key_Backtab` versus `Shift+Tab` spelling.

The matching trim for "fix: stop treating long-time Mudlet users as
brand new players" (#9695) already landed separately as #9707, so it is
not repeated here.

No demo video: a comment-only change is not observable on screen.

**Test case:** `ctest` in the build directory - 79/80, with
`TelnetBenchmark` timing out only under parallel load (31s standalone
against a 60s limit) on a path this PR does not touch.
`TriggerSameLineMatchTest`, `UnitDeferredDeleteTest`,
`ProfileSwitchShortcutTest` and `ExperiencedPlayerGateTest` all pass.

Assisted-by: Claude:claude-opus-5
2026-08-06 15:43:35 +00:00
Vadim Peretokin
dbf88336ed
Fix user key bindings on Ctrl+1 to Ctrl+9 and Ctrl+Tab (#9703)
#### Brief overview of PR changes/additions

- The profile tab switching shortcuts added in #9460 "add: keyboard
shortcuts to switch between game tabs" (`b649b60f0`) are `QShortcut`s on
the main window, and Qt's `QShortcutMap` consumes a matching key inside
`QApplication::notify` before the `KeyPress` ever reaches the command
line. `TCommandLine::handleCtrlTabChange()`'s "let user-defined Ctrl+#
keys match first" branch became unreachable, so user key bindings on
Ctrl+1..Ctrl+9, Ctrl+Tab and Ctrl+Shift+Tab silently stopped working.
- `TCommandLine::event()` now claims `QEvent::ShortcutOverride` for
exactly those key sequences when a user binding matches, which is the
same escape hatch the accessibility caret shortcut already uses. Asking
needs a non-executing query, hence `TKey`/`KeyUnit::wouldMatch()` -
`keybindingMatched()` runs the binding and would fire it on every
override probe. The match reproduces `QShortcutMap`'s own retries, so
Ctrl and a numpad digit, and Ctrl+Shift and a digit on layouts that need
Shift for the top row (French AZERTY), are covered too.
- Precedence, stated explicitly: a user binding wins over the built-in
tab switch, which is what that comment always intended. A binding that
is disabled, or sits in a disabled group, does not claim the key, and
every other application shortcut is unaffected.

#### Motivation for adding to Mudlet

Ctrl+1 to Ctrl+9 is a common combat/target hotkey range and the one
Mudlet's own key editor offers. Upgrading silently broke those bindings
with no error and no warning, and the escape hatch (clearing the
shortcut in Preferences) is undiscoverable.

#### Other info (issues closed, discussion etc)

Test case: `ctest -R ProfileSwitchShortcutTest` - 15 cases covering the
claim, the no-claim controls, disabled bindings and groups, the keypad
and shifted-digit spellings, Ctrl+Shift+Tab's `Key_Backtab` spelling, a
cleared shortcut not claiming every key, and that a claimed binding runs
exactly once. Verified to fail without the fix.

Not fixed here, reported instead: the caret-mode Ctrl+Tab toggle lives
on `Host::mCaretShortcut` rather than `ShortcutsManager`, so #9449's
shortcut clash warning still cannot see its collision with the "Next
profile" default.

Assisted-by: Claude:claude-opus-5
2026-08-06 13:33:06 +02:00