We want input gesture identifiers with multiple items of indeterminate order (e.g. multiple keys) to be handled the same way regardless of the ordering of the items. For example, control+shift+f1 should be treated the same as shift+control+f1. To do this, we currently normalise using Python set order. My original thinking was that the output order needs to be consistent regardless of the input order, but it doesn't need to make sense to humans. Set order seemed like an ideal solution, since there's no sorting cost. Unfortunately, while this is often true for set ordering, it isn't true when there are hash bucket conflicts. For example:
>>> # Case 1: The output order is consistent regardless of input order.
>>> {1, 2}
set([1, 2])
>>> {2, 1}
set([1, 2])
>>> # Case 2: The output order is different for different input orders.
>>> {8, 256}
set([8, 256])
>>> {256, 8}
set([256, 8])
(See this StackOverflow thread for details.)
The specific example for case 2 is actually seen in the wild; it is the cause of #3157 (comment). The fact that we haven't seen this elsewhere is just luck. For example, you can reproduce it as follows:
- Open the Python console.
- Enter the following:
import globalCommands; globalCommands.commands.bindGesture("kb:control+windows+f1", "dateTime")
- Try pressing control+windows+f1 in input help.
- Expected: Date time command.
- Actual: Nothing.
To fix this, we're going to need to use some other ordering. Sorting for every gesture identifier seems expensive. This is also going to be painful because all the existing implementations output in set order; they don't call a common normalisation function.
CC @michaelDCurran.
We want input gesture identifiers with multiple items of indeterminate order (e.g. multiple keys) to be handled the same way regardless of the ordering of the items. For example, control+shift+f1 should be treated the same as shift+control+f1. To do this, we currently normalise using Python set order. My original thinking was that the output order needs to be consistent regardless of the input order, but it doesn't need to make sense to humans. Set order seemed like an ideal solution, since there's no sorting cost. Unfortunately, while this is often true for set ordering, it isn't true when there are hash bucket conflicts. For example:
(See this StackOverflow thread for details.)
The specific example for case 2 is actually seen in the wild; it is the cause of #3157 (comment). The fact that we haven't seen this elsewhere is just luck. For example, you can reproduce it as follows:
import globalCommands; globalCommands.commands.bindGesture("kb:control+windows+f1", "dateTime")To fix this, we're going to need to use some other ordering. Sorting for every gesture identifier seems expensive. This is also going to be painful because all the existing implementations output in set order; they don't call a common normalisation function.
CC @michaelDCurran.