From: Omar Polo Subject: Re: tog: don't embded utf8 glyphs in tog.c To: Mark Jamsek Cc: Christian Weisgerber , gameoftrees@openbsd.org Date: Sun, 25 Sep 2022 18:03:51 +0200 On 2022/09/26 01:23:47 +1000, Mark Jamsek 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.