Bug Description
on_text_input handles four keys: Enter and Esc finish, Char(c) pushes to the end, Backspace pops from the end. Everything else falls through to a no-op, so there is no cursor and a typo in the middle of a regex can only be fixed by deleting everything after it. The Char arm has no modifier guard, so Ctrl+U, the standard clear-the-line, types a literal u into the pattern, and so does every other Ctrl+letter. Separately the caret is positioned with input.len(), which is bytes, so any non-ASCII draws the cursor past the end of the text.
Steps to Reproduce
Focus the user filter, type alice, press Ctrl+U to clear it, then press Left or Home to go back and fix something.
Expected Behavior
Ctrl+U clears the field, and Left, Right, Home, End and Delete move and edit around a cursor.
Actual Behavior
after Ctrl+U: "aliceu"
after Left/Home/Delete: "aliceu"
caret x offset for "José": len()=5 chars=4
Ctrl+U appends a u to the pattern being built, the movement keys do nothing at all, and a four-character value pushes the caret five columns.
System Information
sqwatch 0.2.0, source checkout at 4c594fb
Ubuntu 26.04.1, rustc 1.97.1
Both fields hold regexes, which is exactly the kind of text you get wrong by one character in the middle, so append-only editing bites often.
Storing a caret as a character index per buffer covers it: Left and Right move it, Home and End jump, Delete removes at it, Backspace removes before it, and Char inserts at it, with the arm gated on the modifiers being empty or Shift so Ctrl+letter stops being typed. Inserting at a character index needs char_indices().nth() for the byte offset, which is the one spot to be careful and the reason to keep the caret in characters rather than bytes. truncate further down the same file already does the chars() thing correctly.
Not worth pulling in a text-input crate for two single-line fields in a sidebar that already has its own render path. Ctrl+U and Ctrl+W are worth adding once a caret exists, but they are not what makes this a bug.
Bug Description
on_text_inputhandles four keys: Enter and Esc finish,Char(c)pushes to the end, Backspace pops from the end. Everything else falls through to a no-op, so there is no cursor and a typo in the middle of a regex can only be fixed by deleting everything after it. TheChararm has no modifier guard, soCtrl+U, the standard clear-the-line, types a literaluinto the pattern, and so does every other Ctrl+letter. Separately the caret is positioned withinput.len(), which is bytes, so any non-ASCII draws the cursor past the end of the text.Steps to Reproduce
Focus the user filter, type
alice, pressCtrl+Uto clear it, then press Left or Home to go back and fix something.Expected Behavior
Ctrl+Uclears the field, and Left, Right, Home, End and Delete move and edit around a cursor.Actual Behavior
Ctrl+Uappends auto the pattern being built, the movement keys do nothing at all, and a four-character value pushes the caret five columns.System Information
sqwatch 0.2.0, source checkout at 4c594fb Ubuntu 26.04.1, rustc 1.97.1Both fields hold regexes, which is exactly the kind of text you get wrong by one character in the middle, so append-only editing bites often.
Storing a caret as a character index per buffer covers it: Left and Right move it, Home and End jump, Delete removes at it, Backspace removes before it, and
Charinserts at it, with the arm gated on the modifiers being empty or Shift so Ctrl+letter stops being typed. Inserting at a character index needschar_indices().nth()for the byte offset, which is the one spot to be careful and the reason to keep the caret in characters rather than bytes.truncatefurther down the same file already does thechars()thing correctly.Not worth pulling in a text-input crate for two single-line fields in a sidebar that already has its own render path.
Ctrl+UandCtrl+Ware worth adding once a caret exists, but they are not what makes this a bug.