When I'm looking/editing a file in mc, it messes up when trying to display unicode characters. The changelog for eclean-kernel provokes this issue with Michael Gorny's name for example. I get garbage at the end of the line that looks like the line wasn't completely painted/drawn, and often the actual cursor position doesn't match the one indicated at the top of the screen. Suggested solution: Make sure that unicode characters are properly counted. I think you should make sure that wcwidth and wcswidth are being properly used, and that mc isn't naively assuming that one byte is equal to one character, particularly if it's processing UTF-8
Please attach the output of emerge --info app-misc/mc to this bug and post the the output of the command locale into the comments.
Please also provide: - minimal "broken" text file - a screenshot how it's broken - current encoding in mcedit (seen by pressing Ctrl+e)
Created attachment 435390 [details] emerge --info
Created attachment 435392 [details] locale output
...:sigh:... That's actually a well known *upstream* bug (at least IIRC). If you want to see something funny, try, while editing a file with some double-width chars on two subsequent lines, move up/down between them. Sometimes you'll be able to move *into* a double-width char, that is if you try to backspace a char, instead of simply removing the char, you'd end up removing only a part of its utf8 sequence.
(In reply to Rafał Mużyło from comment #5) > ...:sigh:... > > That's actually a well known *upstream* bug (at least IIRC). > If it's a well known bug can you please add the upstream bug URL to this bug?
(In reply to Lars Wendler (Polynomial-C) from comment #6) > (In reply to Rafał Mużyło from comment #5) > > ...:sigh:... > > > > That's actually a well known *upstream* bug (at least IIRC). > > > > If it's a well known bug can you please add the upstream bug URL to this bug? ...OK, it seems I stand corrected on the *'reported'* part (at least I'm unable to find it in their bugtrack), yet that's still a long-standing *upstream* problem. I still recall the time, when utf8nsupport was provide by a mostly-working external patch, and while mc has made a significant progress since, issues like these are still not that hard to find, if you start looking. If you're switching from a single-byte to variable byte length and add variable char width on top of it, such problems are pretty much expected and sprinkled all over the code. If you want more, there's an unrelated one: in copy/move dialogs, if you Esc-Tab a path containing spaces, mc will backslash-escape the completion, but won't go any deeper with the completion unless you remove those backslashes. I'm too used to the interface (and a few functions) to drop it, but major warts....
(In reply to Rafał Mużyło from comment #7) > ...OK, it seems I stand corrected on the *'reported'* part (at least I'm > unable to find it in their bugtrack), yet that's still a long-standing > *upstream* problem. I cannot guarantee you that this bug will be fixed if you report it upstream, but I can guarantee you, that it will *never* be addressed if you don't do so. A proper report upstream with a minimal reproducer + screenshot as requested by @slyfox will be appreciated; Egmont has fixed a number of similar / related problems in the past, and I'm sure that he can look into it if asked kindly. > If you want more, there's an unrelated one: in copy/move dialogs, if you > Esc-Tab a path containing spaces, mc will backslash-escape the completion, > but won't go any deeper with the completion unless you remove those > backslashes. Same here.
Sorry ^^ I thought it was the gentoo level maintainer for this package that had the responsibility of making upstream reports. I've been waylaid irl with drama.
So far I didn't see any of this in this bug (comment #2): - minimal "broken" text file - a screenshot how it's broken - current encoding in mcedit (seen by pressing Ctrl+e) Closing as INVALID.
