On 23-04-19 10:21AM, Stefan Sperling wrote:
> 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.

I think the heuristic made sense and worked as intended. But naddy is
right that we shouldn't have to workaround incorrect data.

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

I'm definitely happy to defer to naddy too! It's a huge black box for me
despite using them since ~1990 :)

I just didn't want to be presumptuous and wanted to make sure I hadn't
overlooked any other reasons for the check.

so ok for me too

-- 
Mark Jamsek <fnc.bsdbox.org|got.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68