Tony Balinski wrote: > Can we just check this in?
If you ask me, yes I'm certain the fix is correct. If there is no whitespace at the wrap point, two possible display positions for the cursor have the same buffer position, namely the line end at the wrap point and the start of the next (displayed) line. (If there is an whitespace, these positions differ by one.) Now, where to put the cursor given the buffer position? NEdit chooses the start of the next line. This may look surprising, but recall that end of line and start of next line have the same buffer position in this case, so if one chooses the end of the line to display the cursor this would also be the start of the next line, which isn't less surprising. The example in the bug report sets the wrapmargin to, say, 20, sets the cursor to the end of the first line containing exactly 20 chars to get a preferred column size of 20 when moving down. The next line is 22 chars, contains no whitespaces, so the last two chars are wrapped and hitting Down the cursor is positioned at the start of the third (displayed) line. Then, hitting Up goes to the start of the previous (= second displayed) line, counts preferred column = wrapmargin = 20 chars to right and lands again at the current cursor position. This is the reported hang up. All what was missed is that while being displayed at the start of the third line the cursor is virtually at the end of the second line, still, and it is the first line to go back to. This happens if the cursor is at the start of a line and at the same time the preferred column size is equal to the wrapmargin. (For the more common wrapping at whitespaces this condition cannot hold, because if the preferred column size equals the wrapmargin the cursor must be at the end of a line and if the cursor is at the start of a line the preferred column size is 0.) Jörg -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
