Re: address@hidden: Still Active?]

[Thomas Dickey]

On Mon, 20 Jun 2005, Bob Rossi wrote:

> On Mon, Jun 20, 2005 at 04:24:16PM -0400, Thomas Dickey wrote:
> I was wondering if I might ask about the ACS_VLINE variable. I'm writing
> a curses based interface to the GNU debugger (GDB). Unfortunately, when I
> use the ACS_VLINE char, some users have reported that the terminal looks
> incorrect.
>
> It could very well be a configuration error on my part, and I was just
> hoping to get some advice on the use of this variable. I use the
> variable like this,
>   waddch(win, ACS_VLINE);
> am I supposed to check the system somehow to see if the terminal
> supports this char? or does ncurses do that for me? Any other info would
> be greatly appreciated.

All of the ACS_xxx symbols are given as a mapping, in terms of the acsc
string in the terminfo entry.

ncurses (tries to) check if the terminal support line-drawing characters
by looking at the acsc string (terminfo entry).  If that is missing or
incomplete, ncurses uses the substitutions listed in the addch manpage
(Line Drawing).

If it (acsc) is present and defines a mapping for the given character
('|' for ACS_VLINE), ncurses may still modify that to handle some common 
cases of UTF-8 locales.  A few easily tested cases (Linux console and
GNU screen) can be detected by checking the $TERM variable.  Those don't
honor the terminfo strings for line-drawing when in UTF-8 mode.

Some other terminal emulators also don't, but since their implementers 
chose to claim that they're compatible enough with xterm to set their 
$TERM to "xterm", there's not much to be done automatically for them 
(xterm works correctly ;-).

ncurses 5.5 (upcoming) has an environment variable that can be set for 
those: NCURSES_NO_UTF8_ACS.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net