This time I actually ran them all. I also opted to have get return the
internal slice rather than make multiple copies of the input on each
invocation. It just sort of bothered me to leave it like that.
This commit adds support for left/right arrow in Searches and Prompts (and, by
extension SelectWithAdd Adds).
It does so to support use cases were user input can be computed except for a
single characters, which is not always on the right hand side of the default
input. E.g. my app, an exercised journal, has a field for how far I swam.
Yesterday I input that I swam 1600 meters. Today, I shouldn't have press delete
three times in order to modify the 6 to a 7.
To support this use case I added:
1. support for specifying your cursor, since the default one obscures the
rune under it
2. support for moving cursor over existing text
3. support for editing input from wherever the cursor happens to be
4. Update the prompt and select structs to permit specifying a
cursor
The cursor positioning math is limited to the Cursor struct, in
promptui/cursor.go. It is documented and tested.
It has consequences on both prompt.go and select.go, which as far as I can tell
did not have tests covering the logic I modified. I verified their functioning
by running the app mentioned above.
Note: I made a design choice that could be wrongheaded-- I moved the cursor to
the front of `"AllowEdit: false"` default text, and made it so that if the user
attempts to → into the default text, we allow them to edit it. I did so because
to my mind moving into the text is a clear indication that the user would like
to change it, and it is better to support the user than enforce arbitrary
rules. I could be convinced otherwise.
