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 :)