Download raw body.
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. 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. > Alternatively, of course, we could drop the use of ACS_* and always > use ASCII characters. I wouldn't like to take this approach. I think the ACS_* characters look nicer than | and -, and I am far more often using tog in xterm where acsc is supported. So of the two, I would prefer ?s in the console than -| in xterm :) > Then the screendump issue can be revisited. I think the overwriting > of vline/hline should be removed, too. > > -- > Christian "naddy" Weisgerber naddy@mips.inka.de > -- Mark Jamsek <fnc.bsdbox.org|got.bsdbox.org> GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68