stb_textedit: fix find_charpos for n == z to make cursor move correctly when pressing up #1694
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, when the cursor was at the very end of the text in multiline mode (no trailing newline), pressing the up key did either nothing or set the character to the start of the same line.
This is because in this specific case (multiline mode, n == z)
stb_textedit_find_charpos
returned a strange find result with the found line being the next one (non existent) and the previous line being the actual line of the cursor.So when the following code searched for a character in the "previous" line it really searched in the current one. With preferred_x, nothing happened (it found the same cursor position), without preferred_x it searched for the character in the "current" line (where x is 0), so the character got set to the start of the line.
I think the whole n == z check can be removed if the layout row loop breaking condition is modified.
With this change in single line mode,
stb_textedit_find_charpos
returns the same result if two conditions are met:r.num_chars == z
(causing the layout row loop to break immediately)r.x1 == r.x0 + sum(STB_TEXTEDIT_GETWIDTH(str, 0, i) for i in [0, n-1])
I assume both of these should be true.
With this change multiline mode,
stb_textedit_find_charpos
returns a very differnt result, but this is desired and more consistent with the result for the rest of the characters in the last row.The upside of this change is that it fixes the issue and makes the code shorter, the downside is that the loop condition is a bit more complex and that the found line is scanned for the character position instead of just returning
r.x1
(like previously in single line mode).