Add title-to-title scroll feature to Help Menu

[Niloth-p]

What does this PR do, and why?

Adds 2 new commands to refocus to view the previous/next help category section.

Hotkeys linting exclusion updated.
Hotkeys document regenerated.

Why?
This could be helpful when we have several help menu sections.

Outstanding aspect(s)

• Would need to come up with a better way to display the navigation keys inside the Help Menu.
  This merely adds the functionality. The prompting for the user can be improved.
• We could add an extra field to key bindings - something like exclude_from_help_menu to remove entries like these from being listed in the help menu. Currently, these are probably the only 2 commands that may need to be removed from the help menu, but with the addition of contexts, there may be more.
• Does not add any tests

External discussion & connections

• Discussed in #zulip-terminal in New hotkeys to scroll title-to-title in Help Menu #T1527
• Fully fixes #
• Partially fixes issue #
• Builds upon previous unmerged work in PR #
• Is a follow-up to work in PR #
• Requires merge of PR #
• Merge will enable work on #
• Merge may or may not help with work on Group narrowing commands and improve descriptions #1516

How did you test this?

• Manually - Behavioral changes
• Manually - Visual changes
• Adapting existing automated tests
• Adding automated tests for new behavior (or missing tests)
• Existing automated tests should already cover this (only a refactor of tested code)

Self-review checklist for each commit

• It is a minimal coherent idea
• It has a commit summary following the documented style (title & body)
• It has a commit summary describing the motivation and reasoning for the change
• It individually passes linting and tests
• It contains test additions for any new behavior
• It flows clearly from a previous branch commit, and/or prepares for the next commit

[rsashank]

LGTM! @Niloth-p 👍
Just requires a rebase to fix conflicts. The intention seems clear.

[zormit]

Generally this seems to work fine. Also I personally like these two keys. So if we decide it's something to add (the Zulip thread doesn't have a definitive answer to that question yet), this could be the way to go.

I have left some comments, they are a bit more like "questions" than answers unfortunately, I'd be happy to help looking for answers. Gist is that I think the code can be iterated on a bit.

Also, did you consider writing tests? ("yes, but decided against them because it's too tricky" is a valid answer)

[zormit]

I'm not sure whether navigation is a good category for this, but I don't see a better one either. The problem I see is that the two new commands are very specific to the "Help" popup while the other ones seem to be more generic. In that sense the new commands seem to be a bit similar to "Show/hide user information (from user list)": It could also be "Go to previous category (in Help Menu)" or something like that.

[zormit]

I am also wondering whether it's useful to put hints towards those keys in the headline of the popup. It probably will get a bit crowded there.

[neiljp]

For future reference, see the linked topic for some discussion. The keys aren't critical here, but my thoughts would be to use ones that

• don't clash with existing more-global key use (like n & p; so don't need to remember context)
• more easily translate to use more globally in the UI (reuse/memorization; can apply to other vertical sectioned lists)
• have relative movement (like these, but not eg. numbered points to jump to)

Some options I raised were perhaps tab/shift-tab (depending on usage of that elsewhere), and various matching parentheses such as (/), or ], or }.

[zormit]

My LSP (I think) shows me a type error here. I think this file is not typed, so the CI passes on github. The error is:

Operator ">" not supported for types "int" and "Unknown | None"
Operator ">" not supported for types "int" and "None"

Which might be caused by the previous # type: ignore[misc]. I would be curious if there's a way to make mypy happy without the ignore.

[neiljp]

For reference, I think this was caused by using a later version of Urwid here.

[zormit]

It's mainly independent of this PR, but it seems a bit strange to me to have a super().__init__ call in the middle of a constructor. I would have expected it at the start of the constructor, but that doesn't seem to be a pattern in Zulip Terminal.

It seems that the general pattern is to have the super init at the end. But now that the setup code for category_start_positions relies on the parent to be initialized it lands in the middle.

Nevertheless I'd be curious if that's also something we can prevent, maybe by putting the responsibility for the category positions to the parent or something.

[neiljp]

@Niloth-p For some more direct feedback here, this looks to work OK, though I've not reviewed the code as there are other PRs underway!

Points to consider:

• ?, n/p 'scrolls' quite cleanly (if abruptly, like J/K)
• ?, jj, n leaves me half way into a category (navigation), needing kkkk to show the title?

Right now this works well separately from scrolling, but including that it gets confused - at least if the intention is to have a category title visible at the top? (on each title-to-title, except if the bottom is not 'aligned')