bug-ncurses
[Top][All Lists]
Advanced

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

Re: Line-drawing constants


From: Ian Lynagh
Subject: Re: Line-drawing constants
Date: Wed, 17 Jul 2002 14:11:25 +0100
User-agent: Mutt/1.3.25i

On Wed, Jul 17, 2002 at 08:19:15AM -0400, Thomas Dickey wrote:
> 
> ncurses's definitions were based on SVr4 header files, which use an
> array. Checking, I see that Solaris' xpg4 header files do use a
> constant here as you've indicated (while the legacy curses doesn't do
> that).  Perhaps what I'll do is modify the ncurses headers so that if
> _XOPEN_SOURCE_EXTENDED is defined, it would use the constants - but
> retain the other definitions for legacy apps.

Would it not be possible to switch to using constants by default but
still export (and overwrite etc) the acs_map array for programs compiled
against an older version of the library? And then acs_map could
completely dropped in ncurses6. Even people being naughty and doing
things like ACS_BLOCK + 1 ought to be unaffected.

> > My reason for emailing is that I am writing code in Haskell and your
> > interpretation is making the curses interfacing quite inconvenient.
> > Do you believe it is a legitimate interpretation of the standard?
> 
> I suppose so - but I think you'll find you would have to solve the
> same issue with other versions of curses.

By "I suppose so" do you mean you suppose it is legitimate? It
doesn't seem to quite fit with what you are replying to.

I'm not actually worried about whether it is portable in practise - it
is really an experiment/proof of concept app rather than one I expect to
really be used. However I would like it to work in the common
environments (of those interested) and to comply with all the relevant
standards, so ncurses working how I expected (or my reading of the
standard being corrected if applicable) would be a great help.

> Perhaps the real issue is that the X/Open documentation was written by
> people who were not familiar with the interface that they're
> describing - there's more than one instance of blunders introduced
> into their descriptions by sloppy editing while attempting to improve
> the terminology (tgetent, for instance). 

:-(


Thanks
Ian




reply via email to

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