Why is tab unaffected by font whereas space is affected?

Eli Zaretskii eliz at gnu.org
Mon Apr 20 09:18:40 CDT 2020


> Date: Sun, 19 Apr 2020 14:36:16 -0700
> From: Asmus Freytag via Unicode <unicode at unicode.org>
> 
> No.  On a GUI display, Emacs shows a TAB as a stretch of white space
> of a suitable width, not as a string of space characters.
> 
> On a GUI display, no whitespace character is a rendered glyph. All are effectively control functions.

Maybe conceptually.  In practice, on GUI displays Emacs displays a
space by using the font's glyph for that character.  It doesn't do
that for TABs (or other low ASCII control characters, for that
matter).

> TAB requests that layout proceed from the next tab position beyond the width of the already laid out text.

Emacs is primarily a programmer's editor, and it allows the user to
define the width of a tab stop, in units of the font's space character
width.  It then produces a stretch of white space whose width is
computed to end at the next tab stop, as customized by the user (via a
variable that is local to the buffer of text being displayed).

> Just because it's proven a useful workaround to scale default tab positions based on font size and typical
> width (using the space character as a proxy) it does not follow that tab-stop positioning is now a per-font run
> property. It is not.

I just described what Emacs does, because someone described that
somewhat inaccurately.  HTH.


More information about the Unicode mailing list