Download raw body.
tog: don't embded utf8 glyphs in tog.c
On 22-09-25 06:19PM, Stefan Sperling wrote: > On Mon, Sep 26, 2022 at 01:23:47AM +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]. > > > > > Why not simply use <...> everywhere? > > > > This is what we do if the user has not set a UTF-8 locale. We also do > > this with borders, for example, and use one glyph if UTF-8 is enabled > > and another if not. > > These borders are actually VT100-related, not UTF-8. > > The ACS_VLINE and ACS_HLINE macros are defined by ncurses and can be > passed to routines like addstr() to make them appear on the terminal. > In fact, ACS_VLINE and ACS_HLINE look the same in a UTF-8 locale xterm > and in a C locale xterm. > > The reason that our use of ACS_VLINE and ACS_HLINE is only enabled in > the UTF-8 locale is that those symbols don't look as they should on the > OpenBSD glass console. The font the console is using is very limited. > People usually leave UTF-8 disabled on the console, so the UTF-8 locale > check just works around the glass console font limitation. > > There are ACS macros defined in ncurses.h which we could probably use > for the help view's purposes if we really wanted to avoid UTF-8. > For example, ACS_LEQUAL and ACS_GEQUAL. > I don't mind using UTF-8 for this, but if naddy has concerns then > the ACS macros might provide an alternative we could consider. > You can't write these ACS macros to a file and read them back, though. > They need to be passed directly into ncurses function calls. > Oh, that's good to know! And, yes, if naddy wants to drop the guillemets, then this might be a workable solution. Thanks, Stefan! -- Mark Jamsek <fnc.bsdbox.org> GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68
tog: don't embded utf8 glyphs in tog.c