[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Still Active?]

From: Thomas Dickey
Subject: Re: address@hidden: Still Active?]
Date: Mon, 20 Jun 2005 17:31:42 -0400 (EDT)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]