This is just getting a feel for how I'll go about testing these. The main
focus here won't be on the bindings themselves -- they're not really
interesting and I feel could change over time anyway as people's tastes
settle down. What I want to test here are the actions that get bound.
This is just an initial small set of what's going to be a much bigger
collection of Input action tests.
I'm going to be adding more tests for Input, and I don't want to be doing
one large monolithic file of them, so this makes a space where
Input-targeting tests can live together and be easy to spot.
This makes no difference to anything; but I think grouping the bindings into
similar groups will make it easier for folk to read and find things.
See #1310.
This makes no difference to anything; but I think it makes for code that's
easier on the eye so someone scanning down the list of bindings will see the
more descriptive key first.
See #1310.
And in doing so bind it to Ctrl+U (readline-common). Right now I'm not aware
of a common combo for this on Windows, but we can add a binding for this if
one becomes apparent.
See #1310.
And in doing so bind it to Ctrl+K (macOS/Emacs/readline-common). Right now
I'm not aware of a common combo for this on Windows, but we can add a
binding for this if one becomes apparent.
See #1310.
While descriptive keywords tend to be a preference within the Textual
codebase for many things, this was one of those times where a developer's
code using the library was likely going to read better if there's a switch
to using dedicated methods; this approach means we can just go with "all"
rather than "{action}_all" without needing to shadow a Python builtin.
This also does mirror mount/mount_all too.
