From: Stefan Sperling Subject: Re: tog test harness To: Mark Jamsek Cc: Christian Weisgerber , gameoftrees@openbsd.org Date: Wed, 19 Apr 2023 10:21:54 +0200 On Wed, Apr 19, 2023 at 06:13:01PM +1000, Mark Jamsek wrote: > On 23-04-18 04:53PM, Christian Weisgerber wrote: > > Mark Jamsek: > > > > > IIRC, this was a hueristic used to determine whether tog was being run > > > in the console because there they are rendered as '?' so we use | and > > > - instead. > > > > I see. > > > > The problem is setting TERM on the console to a terminal type whose > > description advertises support for the alternate charset capability, > > when the console doesn't actually support it. That's a problem of > > wscons(4). Applications can't be expected to work around that. > > > > So as a first step I suggest removing this bizarre workaround: > > > > -------------------> > > --- tog/tog.c > > +++ tog/tog.c > > @@ -982,11 +982,10 @@ view_border(struct tog_view *view) > > view_above = panel_userptr(panel); > > if (view->mode == TOG_VIEW_SPLIT_HRZN) > > mvwhline(view->window, view_above->begin_y - 1, > > - view->begin_x, got_locale_is_utf8() ? > > - ACS_HLINE : '-', view->ncols); > > + view->begin_x, ACS_HLINE, view->ncols); > > else > > mvwvline(view->window, view->begin_y, view_above->begin_x - 1, > > - got_locale_is_utf8() ? ACS_VLINE : '|', view->nlines); > > + ACS_VLINE, view->nlines); > > } > > > > static const struct got_error *view_init_hsplit(struct tog_view *, int); > > <------------------- > > I'm reluctant to do this without stsp's ok because while I'm somewhat > sure of the reason behind this workaround, I'm not 100%. > > Plus, this might confuse users when they start seeing ????? appear in > their tog sessions. As far as I recall the reasons for the utf8 check was indeed that it looks ugly in wscons otherwise. Assuming that people wouldn't enable UTF-8 on wscons because it doesn't work there. But that might be changing with time. The issue also exists in tmux, which has ugly borders in wscons. But if this is indeed a wscons limitation then I agree that we should just let it look ugly until it gets fixed. > That said, I'm not averse to the change. As you say, the console's > default vt220 term reporting as acs_chars capable is outside tog's > control, so your diff does the right thing. I'd just like stsp's ok, too, > in case I've missed something wrt why we use that workaround. I don't understand how any of this terminal capability stuff really works. I am not using computers for long enough to have gone through generations of terminals and quirks. I'd rather remain in blissful ignorance and defer to naddy's judgment on this :)