Description of problem: less doesn't correctly handle underlined UTF-8. Version-Release number of selected component (if applicable): less-378-5 How reproducible: 100% Steps to Reproduce: 1. Start gnome-terminal. 2. echo -ne '\137\010\342\200\220\012' | less Actual results: ??? (first '?' underlined) Expected results: - (underlined) Additional info: Seems to have the same cause as bug #83376.
Created attachment 89807 [details] less-378-multibyte.patch This patch fixes it for me.
Fixed package is 378-6.
Created attachment 89869 [details] Test to test UTF-8 Sorry but UTF-8 is still broken. less-378+iso247-20030108.diff is the reason why it is broken. Quite frankly, this is a patch that makes quite a few assumptions on how multibyte scripts work and probably breaks other non CJK centric multibyte encodings. There used to be a patch for less to support CJK. The authors had given up the idea of supporting non ISO2022 scripts and thus the compiled patched less was called jless so that it could coexist alongside plain vanilla less, letting the user choose to use one or the other. If this is the same patch or a derivatif of it that you are using I would advise you to just drop it or create a jless package. Try reading the attached file to convince you how much less is broken. It works fine with the forementioned patch. Another possible test: read a man page in an xterm. "man man" is a good example :-)
less-378-7 is the real fix. Part of the patch was missing.
Fix confirmed in less-378-11.1.