I run Emacs in my terminal, which is primarily kitty on macOS, but I'm experiencing the same (what I'm about to describe) with other terminal emulators:

In my shell LANG is en_US.UTF-8 and I have fonts installed so that pretty much any unicode point can be displayed, e.g. Symbols for Legacy Computing.

If a text file (C source code or whatever) contains such symbols and I open it in Emacs and scroll up and down, the buffer gets visibly "corrupted". It's especially noticeable with vertical splits, where the corruption involves visual spill over between the buffers. It's a purely visual thing, the file on disk is not affected.

Other CLI and TUI programs don't seem to have that problem: nano, vim, cat'ing the file to less. Is there something I can do to fix the problem in Emacs, or is it a known limitation/bug?

Example file: abi/constants.nim, scroll to the end.

visual corruption in Emacs

If I run Emacs bare, it's not as severe but the problem is still evident

visual corruption in Emacs bare

I'm running macOS 13.3, kitty 0.27.1, Emacs 28.2. TERM is xterm-kitty.

With that setup I've also tried iTerm2 3.5.0-beta10, Terminal.app 2.13, WezTerm 20230326-111934-3666303c (TERM is xterm-256color for those) — I experience the same problem, so it doesn't seem to be terminal-specific.

From searching commits: kitty supports Unicode 15, iTerm2 supports at least Unicode 13 and likely newer, WezTerm supports Unicode 15. Terminal.app (ships with macOS) is not open source, but symbols added in Unicode 13 are displayed correctly.

I've also tried with the Emacs GUI (28.2, downloaded from emacsformacosx.com) and experience a similar problem.

enter image description here

Running the GUI bare doesn't make a difference.

enter image description here

  • You should search for duplicates; there are a few common issues in terminals. Your TERM variable might be set wrong, Emacs and Kitty might disagree about whether a character (or set of characters) count as double width or not, etc, etc.
    – db48x
    Apr 5, 2023 at 17:40
  • And you should add a screenshot, and record which versions of Emacs and Kitty you are using, and which versions of Unicode they claim to support.
    – db48x
    Apr 5, 2023 at 17:41
  • Thanks for the feedback, @db48x. I don't often post to stack exchange (overflow, et al.). Do you think I should follow up on your advice by editing my question, or via comments on it? Apr 6, 2023 at 2:10
  • 2
    By editing the question. Assume that the comments could be deleted, and strive for a question that others in your situation could find useful.
    – db48x
    Apr 6, 2023 at 2:46
  • I have scrolled over the file you have linked. No problems. Fast scrolling clear glyphs. No sign of any corruption. Emacs 29.0.60 lucid (uses X), Linux Mint 21 Cinnamon.
    – Claudio
    Apr 6, 2023 at 6:16

1 Answer 1


Your terminals just aren’t rendering those characters at the same width that Emacs expects them to be rendered. Emacs expects some of those characters to take up two character cells, but your terminal is rendering them in one.

Emacs stores this information in a variable called char-width-table. You can query the width that Emacs expects using the function `char-table-range.

For example, you can check the expected width of one of the angle block characters like this:

(char-table-range char-width-table ?\U0001fb42)

For me this returns 2, but your terminal rendered that character inside a single cell. (You can find out what character is at point using C-x =.)

You could improve the display by carefully setting values in char-width-table using (setf (char-table-range char-width-table ?\U0001FB42) 1) and similar instructions (use C-h f to see the help for char-table-range for more information about specifying larger ranges in one go).

Or you could use the Emacs GUI, which will use the exact pixel widths of the characters as reported by the font used to display them, and avoid all this nonsense. This is my recommendation; there is a lot that Emacs cannot do when stuck inside of a terminal.

  • Thank you for the in-depth answer. A user of Emacs on Linux commented on my question earlier and noted he doesn't experience the problem I reported. I'm not sure what setup you're running, but maybe you and he make for two reports that it's not a problem experienced on Linux / not-maOS (small data set, to be sure). Given I've tried in several terminals compiled from totally different codebases, do you think there could be a bug in the stdlib that's used by my compiler, e.g. buggy wcwidth in Apple's Xode clang? I'll continue to research the problem per your recommendations. Apr 8, 2023 at 3:20
  • The exact same problem exists with most terminal emulators, regardless of OS. Not all of them use wcwidth. I don’t think that Emacs uses wcwidth at all. Either update char-width-table so that it is correct for your terminal, or use the GUI.
    – db48x
    Apr 8, 2023 at 5:17
  • See the screenshots re: the Emacs GUI I added to to the bottom of my question. The problem doesn't manifest in quite the same way visually, but seems related. Apr 8, 2023 at 16:46
  • The following elisp code fixes the display problem in my terminal: (set-char-table-range char-width-table '(#x1fb00 . #x1fbf9) 1) It does not resolve the display problem in the Emacs GUI. However, I use the GUI so rarely I'm not presently concerned about it. Apr 8, 2023 at 20:35
  • The char-width-table is not used by the GUI, as I already told you. The GUI simply couldn’t find a font with the correct glyphs, which means changing your font settings may help. Be aware that you may not even have fonts with these glyphs in them; it is very common for terminals to draw them without the aid of fonts.
    – db48x
    Apr 8, 2023 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.