LociOiling Lv 1
Foldit users can enter text in several spots. The spots include built-in features like segment notes and the save solutions dialog. Textboxes created by recipes are another spot.
All these different text inputs seem to include a common glitch. When text is selected, most applications delete it when the user types something. In Foldit, the general rule is the selected text is not deleted. Instead, the new text is usually inserted at the beginning of the selected text.
For example, enter "foodle noodle" in the "Notes" field of the segment information window. Then select the text and type "before". The note becomes "before foodle noodle". In most applications, you'd get just "before".
Text input has worked this way since the new system launched about 2.5 years ago.
I just recently noticed that there are a number of exceptions. In the "foodle noodle" case, select the text and type "after". You get just the word "after". I'd consider that standard behavior.
The alphabetic keys that work this way include:
a A c C e E v V x X y Y z Z
Keys which include only punctuation on a standard US keyboard also work in the "correct" fashion, deleting the selected text. These include:
. < , > / ? ; : ' " [ { ] } \ | ` ~
The number keys 0-9 and the punctuation above them follow the non-standard "insert" rule.
The combination of "insert" plus the exceptions make text input very confusing. The rule should be that typing overwrites any selected text.
The undo function via control + z or the equivalent is also a little off in these text fields. It seems like there's a relation to the selected text issue.
If you select the "foodle noodle" text and type "a", one undo gets you a blank field. A second undo gets you back to "foodle noodle". The standard behavior in other apps seems to be to restore "foodle noodle" on the first undo.
Selecting "foodle noodle" and typing a non-deleting character gets different undo results. For example, typing "fine idea, " gets you "fine idea, foodle noodle". With the first undo, it may become "fine foodle noodle". On the second undo, it becomes "ffoodle noodle". The third undo gives "foodle noodl", then "foodle nood" on four, and "foodle no" on 5 undos. The control + z hotkey seems a little like backspace or delete, except it seems to take away more than one character at times.
The undo behavior for the "fine idea, foodle noodle" example also seems to vary. The first few undos seem to work almost like the results listed above, but with slight differences. After five undos, it's no longer clear whether the text shown was actually entered.
Maybe some parts of the system are still relying on the "one character, one byte rule" from the old days? That won't work with UTF-8 encoding.
In a text box, the undo key should either undo the last character typed or the most recent typing. Non-modal text editors tend to undo the last chunk of text, for example up to the last backspace. Modal editors like vim, which has a separate input mode, tend to undo all typing.