Cursor missing from end of lines

[pjbroad]

@gvissers

The TTF changes appear to have caused the cursor for text widgets to not show at end of lines. An example is when using the notepad. I've investigated and it looks to be in Font::draw_messages().

At line 1100 of font.cpp, there's and if block that does not appear to be executed:

    if (i_total == cursor)
    {
        if (cur_x + cursor_width <= options.max_width())
        {
            cursor_x = cur_x;
            cursor_y = cur_y;
        }
        else if (cur_line + 1 < options.max_lines())
        {
            cursor_x = x;
            cursor_y = cur_y + block_height;
        }
    }

If I move this block inside the while(true) loop, the cursor is show correctly. However, you have clearly altered the function from the original, and set the cursor position elsewhere within the loop so I'm guessing you had some other intention.

Also, even with this change, there is still a bug. For long lines where the next character would not fit on the same line, the cursor is moved to the next line rather than to the end; fine. This however, results in jumping two lines with the next up arrow. This particular bug is present in the original code too.

Interested in your thoughts and in a proper fix :)

[gvissers]

The first issue you mention is actually caused a bit higher up inside the loop, where upon seeing a newline the code first increases i_total, then checks if it is equal to the cursor position, thereby missing the case where the cursor is on the newline.

But as you have noticed, there are more issues, not all of them new. In general, keeping track of the line the cursor is on is a bit hit and miss in the text widget. As an example, delete a space at the end of a line, which combines the last word of this line with the first word on the following line. Due to word wrapping, the cursor ends up on the next line, but the text field doesn't notice. And now you can't use arrow up to got to the first line.

I'll go through this to see if I can fix the issues I find.

[gvissers]

I believe I have fixed the issues I have found so far, including the two you brought up in this issue. As far as I can see right now, the text field behaves as expected.

[pjbroad]

Yes, that's much better. Thank you for looking into it and fixing.

[pjbroad]

Fixed by commit: 4ff636d6169b4b82049099b315f18fc1b1ab4870