Cursor/scrollbar bugs when resizing the paintbox

[himselfv]

Original report by me.

Originally reported on Google Code with ID 164

Resizing the paintbox (changing width), mainly from showing/hiding docked panels, results
in invalid behavior.

Expected:
Logical cursor position never changes. Text reflows to new width, graphical cursor
position is updated. Text view is updated to start at the same logical position. Editor
scrollbar is updated to match text view.

Observed:
Logical cursor position changes, possibly to some invalid value. Text reflows to new
width, the cursor is nowhere to be seen. Text view is not updated correctly resulting
in different text being on screen after reflow. Editor scrollbar is updated from time
to time, sometimes incorrectly matching current position.

Reported by himselfv on 2013-04-26 08:05:50

[himselfv]

Working on it. Selection bug yet remain.

Reported by himselfv on 2013-05-01 14:40:06

[himselfv]

@r524: The cursor stays at the same logical position (as required), text reflows to
new width, graphical position is updated, but text view is not updated yet and scrollbar
is also incorrect.

Reported by himselfv on 2013-05-13 08:46:09

[himselfv]

Text view reflow rules (expected):
- text view stays at the same logical position when reflowing
- graphical line index may change according to new flow
- when scrolling, new graphical line index is set, setting appropriate logical value
- when reflowing, if there's not enough text to fill the window till the end, graphical
line index changes so that as much of the screen is used as possibl

Reported by himselfv on 2013-05-13 10:34:13

[himselfv]

Probably fixed @r526, may reopen.

Reported by himselfv on 2013-05-16 06:11:46

• Status changed: Fixed
• Labels added: Milestone-1.8.17

[himselfv]

Reopening because resizing the window does not call NormalizeView as it should.

Reported by himselfv on 2013-05-16 07:25:45

• Status changed: Accepted

[himselfv]

Minor bug: one line might be visible partially when aligning for a bottom of the text.

Reported by himselfv on 2013-05-16 07:41:01

[himselfv]

Resizing=>NormalizeView fixed @r532.

Regarding line alignment at the bottom, this happens because the view anchor goes to
the previous graphical line and so the view does move one line up too.

This is not very annoying, but probably not as expected.

I think in the end I should replace ViewPos (logical line + character) with a pair
of "logical line + graphical line offset" and re-verify it every time graphical lines
are recalculated. If there's not enough graphical lines for this logical line, graphical
line index should decrease.

I wonder if I should do it now or close this issue.

Reported by himselfv on 2013-05-16 08:13:31

[himselfv]

Whatever, closing. Existing editors do strange things in such cases too. Might do later.

Reported by himselfv on 2013-05-16 08:15:33

• Status changed: Fixed