-
Notifications
You must be signed in to change notification settings - Fork 905
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Option to Show Default Key Bindings in the Footer #5818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
There are a lot of default bindings. If the footer showed them all, there wouldn't be much or any room left for custom bindings. If you select "Show keys and help panel" via the command palette, it will show you all the keys in a more readable format. |
Thanks for the quick response! Totally understand that showing all default bindings in the footer by default would clutter it — that's definitely not what I'm asking for. What I’d love is the option to selectively include default bindings in the footer (without manually rewriting them). For example, being able to opt-in specific default bindings like "tab" or "shift+tab" with just a label — similar to how custom bindings are defined — but without needing to override or rebind their existing behavior. |
If that’s what you want, then you can go ahead and copy the bindings you wish to see, but set show=True. |
Don't forget to star the repository! Follow @textualizeio for Textual updates. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Feature Request: Include Default Key Bindings in the Footer
Currently, the
Footer
widget only displays key bindings that are explicitly declared inApp.BINDINGS
or bound manually viaself.bind()
. However, many keys such asTab
,Shift+Tab
, arrow keys, etc., have default functionality (e.g., focus movement) that users may not be aware of unless documented separately.Proposal
Introduce a configurable option or parameter to
Footer
(or a global app setting) that allows the display of default/built-in key bindings alongside user-defined bindings.Possible Implementations:
A keyword argument in
Footer
, e.g.:Or an App-level flag:
Default bindings could be labeled with a tag like
[default]
, shown in a different color, or styled subtly to distinguish them from app-specific bindings.Use Case
When building user-facing TUIs, developers want to reduce onboarding friction. Showing helpful default keys like
Tab
for navigation directly in the footer would improve usability without requiring explicit redefinition.Benefits
The text was updated successfully, but these errors were encountered: