The current help is organized into categories, with each hotkey falling into one of these, with a matching description.
As hotkeys have developed over time, they have been placed into best-fit categories, and the placement and categories themselves have been slowly reworked in the past as hotkeys become more widespread. We've now reached a significant set of documented hotkeys, where placement and description has become in need of reworking to improve the utility of the help system.
Improving hotkey category placement has benefits for the general help menu. Hotkey description improvements also have long-term benefits for supporting development work on the contextual help system (#515, #290), with which this work may overlap.
[ ] Find hotkeys missing or not listed in the help
[x] urwid-readline keys (#1494)
[ ] Lint for missing hotkeys
[ ] POSSIBLE adjusting autocorrect hotkey?
(ctrl f=autocorrect, overriding right; ctrl b not documented)
[ ] narrow and composing/replying from user list (#1515)
[ ] narrow from left panel (buttons, not search)
(POSSIBLE to combine button activation with hotkey COMMAND?)
[ ] Indicate/lint hotkeys whose presence in keys.py is for help only
[ ] urwid-readline [library handles all of this] (#1498 ?)
[ ] exiting app via ctrl c? [implicitly handled by signal-handler]
[ ] DISCUSS linting generally for COMMANDS not directly used?
[ ] Clarify hotkeys which are too general
[x] 'Enter' [Do-search vs New-line vs Trigger-widget] (#1497)
[x] 'Esc' [Clear-search vs Exit-compose vs Exit-popup] (#1514)
[ ] Use unambiguous consistent verbs/nouns in descriptions (possibly similar to web app?)
Replace "narrow" with "message view" or others in user-facing documentation like the user tutorial (similarly "narrowing", in some way)
Consider casefix changes to parts of the UI like - All Messages and Direct Messages, possibly when starting to use "feed" terminology
Add a new key binding mentioning that 'Enter' activates narrowing buttons, vs current ACTIVATE_BUTTON
(maybe in a context, since it doesn't fit in an obvious category? See #zulip-terminal>Restructure Key Bindings and Supporting Help Multi-categories #T1519).
Also clarify s/S work in stream/topic, but while s zooms in with DMs, S does not zoom out - this is a benefit of z.
Possible FAQ entry for different hotkeys from web app, explaining history/why?
Description
The current help is organized into categories, with each hotkey falling into one of these, with a matching description.
As hotkeys have developed over time, they have been placed into best-fit categories, and the placement and categories themselves have been slowly reworked in the past as hotkeys become more widespread. We've now reached a significant set of documented hotkeys, where placement and description has become in need of reworking to improve the utility of the help system.
Improving hotkey category placement has benefits for the general help menu. Hotkey description improvements also have long-term benefits for supporting development work on the contextual help system (#515, #290), with which this work may overlap.
ctrl f
=autocorrect, overridingright
;ctrl b
not documented)keys.py
is for help onlyctrl c
? [implicitly handled by signal-handler]ctrl h
(present)space
activates/triggers widgets (#1497)S
? (no longer in web app?) Retain command but hide, for existing users?NOTE:
DISCUSS
is intended to suggest this (or sub-tasks) likely needs further discussionPOSSIBLE
are more speculative pointsFurther summarized points to ensure are integrated:
from @Niloth-p's follow-up points: (https://github.com/zulip/zulip-terminal/pull/1516#issuecomment-2187568271)
Also clarify
s
/S
work in stream/topic, but whiles
zooms in with DMs,S
does not zoom out - this is a benefit ofz
.Possible FAQ entry for different hotkeys from web app, explaining history/why?