Skip to content
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

More input bindings #1676

Merged
merged 34 commits into from
Jan 30, 2023
Merged

More input bindings #1676

merged 34 commits into from
Jan 30, 2023

Conversation

davep
Copy link
Contributor

@davep davep commented Jan 26, 2023

Prompted by #1310, this PR adds additional bindings to the Input widget, and also expands on Input-related unit tests, concentrating on testing the effects of movement and (non-character-input) editing actions.

The actions added to Input are:

  • Move cursor one word left
  • Move cursor one word right
  • Delete a word-worth's of text to the left of the cursor
  • Delete a word-worth's of text to the right of the cursor
  • Delete all text to the left of the cursor
  • Delete all text to the right of the cursor

Additional common bindings have been added too; these include:

  • Ctrl+left to move word left
  • Ctrl+right to move word right
  • Ctrl+a to move to home (common on macOS)
  • Ctrl+e to move to end (common on macOS)
  • Ctrl+w to delete a word to the left
  • Ctrl+f to delete a word to the right
  • Ctrl+u to delete all to the left
  • Ctrl+k to delete all to the right (common on macOS)

The additions are generally either those that are common at the OS level on macOS (if similar key combinations are common at the OS level on other operating systems, do please mention them and/or add them -- note here we're looking at specific key combinations, not "mark and then delete" type operations), or which were suggested in #1310.

Where sensible docstrings have been added to pre-existing actions that were previously lacking them.

davep added 8 commits January 26, 2023 11:43
That is, delete deletes the character to the right -- the opposite of
backspace if you will.

See Textualize#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 Textualize#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 Textualize#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 Textualize#1310.
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 Textualize#1310.
@davep davep self-assigned this Jan 26, 2023
@davep davep added the enhancement New feature or request label Jan 26, 2023
@davep davep linked an issue Jan 26, 2023 that may be closed by this pull request
davep added 16 commits January 26, 2023 21:06
Don't focus on home/end and things like that, and also try and keep all of
the related names related.
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 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.
This should result in a NOP.
There are actions that relate to editing the input too, which I also want to
test, but I'm not minded to lump them all in the same file. So here I'm
renaming to make it clear these tests are just about movement. The editing
ones will come next in their own file.
@davep davep marked this pull request as ready for review January 30, 2023 11:32
@davep davep merged commit 89c799d into Textualize:main Jan 30, 2023
@davep davep deleted the more-input-bindings branch January 30, 2023 15:20
@davep davep changed the title [WiP] More input bindings More input bindings Jan 30, 2023
davep added a commit to davep/textual that referenced this pull request Jan 30, 2023
The idea here is that a password field should give no hint as to what's
within, length notwithstanding. To this end have the actions that (re)move
based on word boundaries act as if a password field is always just one word.

See Textualize#1692 (and previously Textualize#1676, prompted originally by Textualize#1310).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add additional bindings to Input
2 participants