bug-ncurses
[Top][All Lists]
Advanced

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

Re: tty_update: regression in 20180505


From: Thomas Dickey
Subject: Re: tty_update: regression in 20180505
Date: Sat, 1 Sep 2018 20:07:07 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Aug 31, 2018 at 08:03:54PM -0400, Thomas Dickey wrote:
> On Thu, Aug 30, 2018 at 02:01:49PM +0200, Leon Winter wrote:
> > Hi Thomas,
> > 
> > the patch 20180505 contains a change in ncurses/tty/tty_update.c which 
> > screws up
> > the rendering of our ncurses/forms application. It seems that somehow we 
> > end up
> > with space ' ' (32) character has A_ALTCHARSET defined. Before it was just
> > rendered fine but now, instead 0 (NUL) will be the output which in our 
> > terminal
> > (rxvt) is no output at all so all the remaining output is "shifted to the 
> > left".
> > Maybe the new logic is correct and the actual root cause is the logic that
> > generated the space character with A_ALTCHARSET which is not present in the
> > _screen_acs_map but it had worked all the time before. To fix our setup we
> > reverted this change which looks strange to me anyway:
> 
> now that you mention it, it looks odd to me too :-)
>  
> > +       if (!SP_PARM->_screen_acs_map[c8]) {
> > +           chtype temp = UChar(SP_PARM->_acs_map[c8]);
> > +           RemAttr(attr, A_ALTCHARSET);
> > +           SetChar(my_ch, temp, AttrOf(attr));
> > +       }

What looked odd at first sight is that (because the view's small), I
wouldn't have expected to see a character in 'attr'.  But the trace
seems to tell me that...
> > +
> 
> I'll re-examine it, to (try to) eliminate the regression.  That's from
> this change:
> 
>       + fix a special case in PutAttrChar() where a cell is marked as
>         alternate-character set, but the terminal does not actually support
>         the given graphic character.  This would happen in an older terminal
>         such as vt52, which lacks most line-drawing capability.
>  
> > The if-branch ensures there was no match in the translation table and then 
> > uses
> > an entry (from another datastructure though) from such a translation table
> > anyway. Why? And if so, should _acs_map[c8] not also be checked for 
> > NUL-ness?
> > 
> > Is it worth investigating why there was a space with no entry in the 
> > translation
> > table and A_ALTCHARSET?
> 
> probably a good idea.  The alternate character-set normally is just
> graphic characters.

I'd like to get something (even an detailed trace) that shows the data
that led up to this - I wasn't successful in finding a way to break it.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

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