mcview scrolling issues with heavy utf-8 files

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/2283
Reporter	egmont (@egmontkob)

wget http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
mcview UTF-8-demo.txt
Scroll up and down with the arrow (or pgup/pgdn) keys. Notice that very often a partial line appears on the top row, you have to press the arrow key twice or even more times to actually scroll by one line.
This happens when the topmost line that you're scrolling in or out contains lots of non-ascii characters. More precisely, I believe this occurs exactly when the number of bytes forming the topmost row is bigger than the terminal's width.
Buggy both in 4.7.3 and 4.7.0.7, fully UTF-8 environment.

Note

Original attachments:

• mcview-utf8-scroll.png (raw) by egmont (@egmontkob) on Jul 15, 2010 at 13:51 UTC

[mc-butler]

Changed by egmont (@egmontkob) on Jul 15, 2010 at 13:51 UTC

• Attachment mcview-utf8-scroll.png (raw) added

Screenshot - though experiencing the behavior is much more useful

[mc-butler]

Changed by egmont (@egmontkob) on Jul 16, 2010 at 20:25 UTC (comment 1)

Note: the bug only happens when word wrapping is enabled (that is, you see 2UnWrap in the button bar), and happens even despite the terminal being wider than the file.

[mc-butler]

Changed by egmont (@egmontkob) on Jul 16, 2010 at 21:06 UTC (comment 2)

I'm looking at mc-4.7.0.7. Here the bug is in src/viewer/move.c, mcview_move_up() and mcview_move_down() functions, the view->text_wrap_mode branches. The logic that modifies col (e.g. col += width, col -= width etc.) assume that width and bytelenght are the same notions (because col actually means offset in the file), hence does not handle UTF-8 or CJK (double width) characters correctly.

I don't see what the best solution would be, probably someone more familiar with the utf8/width functions of mc could fix it much faster than me.

[mc-butler]

Changed by andrew_b (@aborodin) on Jul 17, 2010 at 6:02 UTC (comment 2.3)

• Blocked by set to #2132

Replying to egmont:

The logic that modifies col (e.g. col += width, col -= width etc.) assume that width and bytelenght are the same notions (because col actually means offset in the file), hence does not handle UTF-8 or CJK (double width) characters correctly.

Yes, this is the known issue. At least the #2132 ticket requires such fix.

[mc-butler]

Changed by andrew_b (@aborodin) on Jul 17, 2010 at 6:03 UTC (comment 4)

• Description edited
• Component changed from mc-core to mcview

[mc-butler]

Changed by andrew_b (@aborodin) on Nov 6, 2011 at 7:22 UTC (comment 5)

• Milestone changed from 4.7 to Future Releases
• Branch state set to no branch

[mc-butler]

Changed by egmont (@egmontkob) on Aug 21, 2014 at 1:13 UTC (comment 6)

Similar scrolling issues are also reproducible with:

• no UTF-8 but nroff formatting (e.g. an English manual page) [same underlying cause]

• no UTF-8 and no nroff either (just plain ASCII text) and a line that's exactly as wide as the widow [the top line becomes empty but doesn't scroll out; probably an off-by-one somewhere]

[mc-butler]

Changed by egmont (@egmontkob) on Aug 21, 2014 at 12:15 UTC (comment 7)

Note that the internal Help viewer also suffers from similar (but different) bug: it always jumps by a whole paragraph rather than one visual line. (The help viewer and mcview seem to be a totally different pieces of code.)

[mc-butler]

Changed by egmont (@egmontkob) on Feb 1, 2015 at 23:18 UTC (comment 8)

This was fixed in #3250, please close the bug.

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 9, 2015 at 10:14 UTC (comment 9)

• Status changed from new to closed
• Resolution set to fixed
• Milestone changed from Future Releases to 4.8.14