bugGNU nano - Bugs: bug #52262, Gnome Terminal shows some...


bug #52262: Gnome Terminal shows some single-width characters as double-width

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sun 22 Oct 2017 06:00:58 PM UTC  
Severity:  3 - Normal Status:  Invalid
Assigned to:  None Open/Closed:  Closed

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sat 04 Nov 2017 06:38:11 PM UTC, comment #2:

Aah! Yes, that was it. I remember trying to get the "code-block" characters (the rectangular things with a six-digit hexadecimal code in them that are displayed for unassigned codepoints or when the font doesn't provide a glyph) to occopy two columns instead of one. This was on a tertiary partition of an old machine that I sometimes use to test nano on. I apparently forgot to restore the default setting. :|

Thanks for clearing this up, Egmont.

(I've read a bit in http://www.unicode.org/reports/tr11/, and the reason that é and such are marked as ambiguous seems to be that in some East Asian legacy character sets those characters were fullwidth ("two columns"). When used in Unicode, however, they should only be rendered as fullwidth when they are used in an East Asian context -- so certainly not when in a Dutch locale and when most of the surrounding characters are plain ASCII.)

Benno Schulenberg <bens>
Project Administrator
Fri 03 Nov 2017 07:58:56 PM UTC, comment #1:

Apparently you've enabled Profile Preferences -> Compatibility -> Ambiguous-width characters: Wide.

This is a silly setting that shouldn't exist as there are no corresponding locale definitions. ncurses (or any other reasonable library or app) believes the affected characters occupy a single column only, whereas actually they occupy two.

At ftp://ftp.unicode.org/Public/10.0.0/ucd/EastAsianWidth.txt you can verify that both "é" (00E9) as well as the arrows (25B6 and 25C0) are marked as ambiguous-width ("A").

Why "é" is marked as such is yet another thing I have no clue about, doesn't make any sense to me.

Egmont Koblinger <egmont>
Sun 22 Oct 2017 06:00:58 PM UTC, original submission:

When running nano from git on Linux Mint 18 (Sarah, based on Ubuntu 16.04, Xenial) and in a Dutch locale, and then typing ^G and paging down to where the cursor commands are (the left and right triangles, etcetera), then this is what I see:

Each non-ASCII character seems to be followed by a space. But that is not actually the case: when copy-pasting the above piece of text to a buffer and moving the cursor over it, the terminal shows the cursor as double-width when it is on one of the triangles or accented e-s. Absurd. These are single-width characters.

And it's not just nano. Also less an vi show the text this way. But the text is rendered fine when doing this on xterm, ROXterm or Sakura. So it seems to be a problem of Gnome Terminal, 3.18.2? Weird.

Benno Schulenberg <bens>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by egmont (Posted a comment)
  • -email is unavailable- added by bens (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-13 bens Open/ClosedOpen => Closed
    2017-11-04 bens StatusNone => Invalid

    Back to the top

    Powered by Savane 3.3