Skip to content

Count only the SetChords bindings that remain, and report the commands that lost their chord [minor] - #215

Merged
matt-edmondson merged 1 commit into
mainfrom
fix/207-setchords-displaced
Nov 4, 2026
Merged

matt-edmondson merged 1 commit into
mainfrom
fix/207-setchords-displaced

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #207

What was wrong

Since #152, BindChord moves a chord that is already in use to the new command. KeybindingManager.SetChords still counted every BindChord call that succeeded. So SetChords({ a: Ctrl+S, b: Ctrl+S }) returned 2 while the profile held 1 binding. Callers also had no way to find out that a had lost its chord.

Change

  • SetChords(chords) now returns the number of bindings from the batch that remain once it has run. The doc comment says so.
  • New overload SetChords(chords, out IReadOnlyList<string> displacedCommandIds) lists the commands whose chord a binding in the batch took. That covers commands outside the batch, and batch entries that a later entry displaced. A command that the batch itself rebinds is not listed if it keeps its new binding; for example, a swap where b takes Ctrl+S from a and a moves to Ctrl+D.
  • The new overload is on KeybindingManager, not IKeybindingService, so no interface member is added for other implementers to provide. It works through the existing BindChord(profileId, …) call, so it also works with an IKeybindingService supplied from outside.
  • The README's batch example shows the overload.

Tests

New cases in ChordConflictTests:

  • the issue's reproduction, through both overloads
  • a chord held outside the batch
  • a swap inside one batch
  • a batch with no conflicts

With the old single-argument body restored, the reproduction test fails (returns 2, expected 1). With this change, the whole suite passes: 333/333.


Generated by Claude Code

…s that lost their chord [minor]

SetChords counted every BindChord that succeeded, so a batch that gave one
chord to two commands reported 2 although the second took the chord from
the first. It now returns the bindings from the batch that remain, and a
new SetChords(chords, out displacedCommandIds) overload names the commands
whose chord was taken, so a settings UI can warn about a displaced binding.

Fixes #207

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW2ncKULZZ8pQtc75wf
Comment on lines +311 to +317
foreach (string holder in holders)
{
if (!chord.Equals(activeProfile.GetChord(holder)) && !displaced.Contains(holder))
{
displaced.Add(holder);
}
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving this one as it is: it's a style suggestion with no change in behaviour. The guard also reads displaced, which the loop adds to, so the explicit if makes that dependency easier to see than a lazy Where would. Happy to fold it in if a later push touches this method.


Generated by Claude Code

@sonarqubecloud

sonarqubecloud Bot commented Nov 3, 2026

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit d21628c into main Nov 4, 2026
15 checks passed
@matt-edmondson
matt-edmondson deleted the fix/207-setchords-displaced branch November 4, 2026 00:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants