With the latest unreleased changes (e.g. 2139f90), conflicting keymaps can be defined by users without warning. The configuration will either be ignored or will shadow another action, depending on an internal, undocumented order of precedence. Therefore, the desirable feature of overriding a built-in key is not properly implemented. Also, if keys are added to tz in future, users’ configurations may misbehave without explanation, due to new clashes. Furthermore, this buggy configuration behaviour was added to tz without unit tests.
Therefore overlapping keymaps should probably be a fatal error, because the behaviour is unpredictable, and because it may be accidental. In this case, a user who wants to override a built-in key, will firstly need to add their desired mapping (as usual) and secondly remap the built-in key (to resolve the ambiguity). This ensures all key mapping are unambiguous and unique.
With the latest unreleased changes (e.g. 2139f90), conflicting keymaps can be defined by users without warning. The configuration will either be ignored or will shadow another action, depending on an internal, undocumented order of precedence. Therefore, the desirable feature of overriding a built-in key is not properly implemented. Also, if keys are added to
tzin future, users’ configurations may misbehave without explanation, due to new clashes. Furthermore, this buggy configuration behaviour was added totzwithout unit tests.Therefore overlapping keymaps should probably be a fatal error, because the behaviour is unpredictable, and because it may be accidental. In this case, a user who wants to override a built-in key, will firstly need to add their desired mapping (as usual) and secondly remap the built-in key (to resolve the ambiguity). This ensures all key mapping are unambiguous and unique.