Re: Aw: Re: Starange behavior of bkgd when called after bkgdset

[Thomas Dickey]

On Sun, Jun 26, 2022 at 12:06:29PM +0200, Anton Vidovic wrote:
> Hello Thomas,
> 
> > > Interestingly enough, Solaris (SVr4) curses does this.
> > > The colors may differ (no bce), but the +'s and -'s match up.
> > >
> > > > sure - if I conclude that it's correct.
> > >
> > > yes... more documentation is needed, to explain this.
> >
> > Actually it's there, in the second bullet:
> >
> >        Wherever  the former background character appears, it is changed to
> >        the new background character.
> >
> > > In the logic which I adapted from Solaris, that comparison against
> > > old_bkgd is checking each cell to determine if the cell used the
> > > same background-character as the old value for the background-character.
> > > If it did not, it leaves that untouched.
> > >
> > > Setting the background character to "+" without filling the screen with 
> > > +'s
> > > produces this special case.
> 
> thank you for the clarification. So the new (since 6.2) side effect of
> bkgdset on the behavior of bkgd is indeed the intended behavior.
> 
> I do not know how big the impact of the change is on existing code,
> but I think that it is a bit unfortunate that the two functions can
> not be used independently any more.

sure - but the difference versus other implementations couldn't be regarded
as an extension.
 
> Specifically, the new behavior excludes the possibility to independently
> set the background/rendition of newly added text and the background
> of the window.

on the positive side, it's documented more clearly now :-)
 
> I also think that it is unfortunate that the concept of a single
> "background character" is now split into the character part and the
> rendition part and that the character is handled differently than the
> rendition.

But when I reread the X/Open and SVr4 documentation, I can see the
distinction there too - but not spelled out so that a developer can
readily see it.  There may still be some error (such as the treatment
of a null character), but improving the documentation also plays a part.

We went through a lot of this in the late 1990s, but I'm still fixing
even older issues :-)
 
> The new behavior may be more compatible to SVR4 behavior, but it seems
> to be less intuitive and less internally consistent. The question that
> arises is whether SVR4 compatibility is still sufficiently important
> today to revert several decades of ncurses behavior.

yes... but I've had to address other issues with more impact (such
as putp buffering and mvwin).  As the years go by, there are fewer :-)

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature