Bug#827905: Character U+2028 can yield file corruption when edited in xterm
On 2016-07-15 05:02 -0400, Thomas Dickey wrote:
> On Thu, Jul 14, 2016 at 07:27:52PM +0200, Sven Joachim wrote:
>> On 2016-07-13 18:24 -0700, Vincent Lefevre wrote:
>>
>> > On 2016-07-13 20:15:49 -0400, Thomas Dickey wrote:
>> >> I don't see the behavior which is described, and haven't seen any
>> >> suitable justification for marking this as a "grave" issue, rather
>> >> than "normal". Keep in mind that this is a rarely used line-break
>> >> character.
>> >
>> > This is not common, but this was sufficient to *silently* corrupt one
>> > of my files (what makes things really worse is that the corruption
>> > doesn't seem to appear immediately, and one notices it when it may be
>> > too late).
>> >
>> >> What I see on the screen is a box-outline for the nonprintable
>> >> character (no space).
>> >
>> > Could this depend on some library version or on the font?
>>
>> On the latter. With the default font I see no corruption, but with the
>> 9x15 font, for instance. See the attached screenshot.
>
> 9x15 is an ISO-8859-1 font, and can't show U+2028
Surely it should just replace it with a space then, like for other
non-latin characters? Besides, the problem also shows up with
terminus-18 which is an ISO-10646 font.
Cheers,
Sven
Reply to: