zulip-terminal
zulip-terminal copied to clipboard
zulip
Render special keyboard keys as shown on keyboard, not as per Urwid
The keys.py file contains details of how hotkeys are used and map to categories, labels, symbolic constants, and so on.
These details are used in the execution of the application, but also when rendering the help menu, as well as when processed into the hotkeys.md document via tools/regenerate-hotkeys.py (current name - see #1326)
However, the entries in keys.py for each action are specifically intended so that urwid can understand them to process keypresses. This means that they are not as clear to application users in the help menu and documentation.
For example, some keys look very similar for lower case and upper case, or do not generally look like they do on common keyboards (though we need to take different platforms into account, eventually)
As a first step to improve this, we need to add a way to map from urwid keys to those as they appear on common keyboards. There are various policies we can try to make this clear to users, but the first step would be:
- implement such a mapping function, ideally with some tests
- use the mapping function in the help menu to render keys differently (without the help menu knowing about the specific mapping taking place
A good starting point to demonstrate this would be making the first letter of keys that have a 'word' for them to a capital letter (eg. Enter)
This can later be built upon to work towards solving #945, though aspects of key rendering may need further discussion.
Hello @zulip/server-hotkeys members, this issue was labeled with the "area: hotkeys" label, so you may want to check it out!
Welcome to Zulip, @Parth576! We just sent you an invite to collaborate on this repository at https://github.com/zulip/zulip-terminal/invitations. Please accept this invite in order to claim this issue and begin a fun, rewarding experience contributing to Zulip!
Here's some tips to get you off to a good start:
- Join me on the Zulip developers' server, to get help, chat about this issue, and meet the other developers.
- Unwatch this repository, so that you don't get 100 emails a day.
As you work on this issue, you'll also want to refer to the Zulip code contribution guide, as well as the rest of the developer documentation on that site.
See you on the other side (that is, the pull request side)!
@Parth576 You have been unassigned from this issue because you have not made any updates for over 14 days. Please feel free to reclaim the issue if you decide to pick up again. Thanks!
Sorry, have been busy with finals! Will start working again from next week once my finals are done.
Hello @Niloth-p, it looks like you've currently claimed 1 issue in this repository. We encourage new contributors to focus their efforts on at most 1 issue at a time, so please complete your work on your other claimed issues before trying to claim this issue again.
We look forward to your valuable contributions!
@Niloth-p You have been unassigned from this issue because you have not made any updates for over 14 days. Please feel free to reclaim the issue if you decide to pick up again. Thanks!
@neiljp if I understand it correctly, #1476 introduces primary_display_key_for_command in keys.py, which is then amongst other places used in the HelpView and hotkey generation via a tool now called lint-hotkeys. Thus this issue looks like it can be closed :) (and if we want to get the metadata correctly, reassign Niloth to it before that)
Update: I picked up from chat.zulip.org#zulip-terminal, that this issue is still kept open because of it's references and associated work.
@zormit Thanks for the note! I was going to leave this as-is, but I agree it's simpler to break this down for follow-up work :+1: