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