TRACKING: Migrate tests using hard-coded keys to use keys_for_command.

[preetmishra]

@neiljp In #523, we migrated keypress tests to use keys_for_command but there are still few other tests that use hard-coded keys. This issue serves the purpose of tracking that.

I grepped the code with keypress to see what tests still use hard-coded keys. I am listing out those here.

• While we migrated a bunch of keypress tests in tests: Migrate keypress tests to use keys_for_command. #523, there are a few which still use hard-coded keys.
• All the mouse_event tests use hard-coded keys. It is not possible to directly use keys_for_command here as their implementation doesn't support all the keys for the commands (more information about this is in the comments).

If you find more tests using hard-coded keys, you can append them here.

[preetmishra]

The mouse_event implementations only support up and down (example) but the keys_for_command for GO_UP/DOWN also have k/j.

[preetmishra]

@zulipbot add "tests (pytest)" "further discussion required"

[neiljp]

@preetmishra The mouse_event code is a little special, as most typically are delegating to the keypress methods, eg. it mimics GO_UP or GO_DOWN.

It is possible that we (or a user) might remove the up or down keys from keys.py, so we should probably rectify the code to use one valid key from the keys instead, which we can then test.

[preetmishra]

@neiljp I have proposed an implementation in #539 that uses keys_for_command to solve this.

[zee-bit]

The mouse_event implementations only support up and down (example) but the keys_for_command for GO_UP/DOWN also have k/j

@preetmishra We could use primary_key_for_command instead; that will only give the up and down keys (or primary ones).
I have a fix for this issue as #953(one of the commits is borrowed from your #539 😅 :).

[neiljp]

Closing this after #953, though we have a very few use of isolated keys (navigation and activation) which will likely be solved using command-map work.