On 2022/09/26 01:23:47 +1000, Mark Jamsek <mark@jamsek.com> wrote:
> On 22-09-24 03:17PM, Christian Weisgerber wrote:
> > Mark Jamsek:
> > 
> > > This fixes the problem stsp reported of making utf8 enabled editors
> > > necessary to browse the code.
> > > 
> > > I also found prettier single guillemets to wrap the control chars.
> > 
> > What are the chances of a font not containing those characters and
> > presenting the user with some replacement box?
> 
> I'm not sure how to get a reliable measure on that, tbh, but will
> investigate further. According to stsp, gnome and xfce support it out of
> the box, I'll learn which other desktop environments also support it by
> default. I can't recall if base xterm did. A cursory search produced
> a couple lists of fonts that apparently support the glyph[0,1]. The
> lists, however, are neither exhaustive nor authoritative; for example,
> spleen also supports it, but spleen is not mentioned. If it were
> a browser app, apparently 95% of users could view it[2].

The default bitmap font used by xterm in base has the left/right
guillemet characters in it, so as soon as one defines LANG (before
spawning xterm) it just works.  (I know because I really like that
bitmap font and happen to use it also for Emacs.)

The tty however doesn't, so if one has a UTF-8 LANG and happens to
open tog in a tty it fails: it renderes the left guillemet as â¹ which
i think is due ISO-8859-1?  This is a problem also with tmux since it
doesn't correctly render the box drawing characters either.

(now that i tried even man(1) fancy quotes aren't rendered in the
tty...)

> > Why not simply use <...> everywhere?

However I kind of agree with this, they have the same width and are
known to work everywhere.