Comment 1 for bug 408571

This is because I used .OrderBy (k => k.Description) in AddBindings ()

This might require a bit more thought than simply removing that OrderBy. The old keybinding code did not organize this list logically based on function, it simply displayed each of the keybindings in the dictionary. With the old code, ALL keybindings were created in just one place, so as long as the "Summon" keybinding was registered first programmatically, "Summon" would show up first on that list.

With the new keybinding code, we can register keybindings from anywhere. That being the case, even if we progamatically register "Summon" first (as your new branch up for review does), it still wouldn't be guaranteed to be the first one on that list, because code somewhere else might beat Do.Controller when registering a keybinding.

Perhaps we could have two sections in the keybinding UI, one for globally (OS level) bound keys, and one for internally bound keys. We could then ensure that globally bound keys always show up at the top of the list, and internal keys show below them.

Or it might even be easier to ditch the idea of categories, and use some LINQ magic to pull any OS keybindings first, add those to the list, then continue adding the rest of the internal keys.

Either way, I agree that globally bound keys should show up at the top of the list, but I still like everything being sorted alphabetically.