On Wed, May 13, 2026 at 09:42:12PM -0400, Frank Palazzolo wrote:
> Hello,
> 
> I discovered an issue with ncurses on Slackware, both version 6.3 used in
> Slackware 15.0 and 6.6 used in Slackware-current.  I was testing a real
> serial terminal - a Tandy DT-1 set to emulate a tvi910.

tvi910|TeleVideo model 910,
        am, msgr,
        cols#80, it#8, lines#24, xmc#1,
                                 ^^^^^
        bel=^G, cbt=\EI, clear=^Z, cr=\r, cub1=^H, cud1=\n, cuf1=^L,
        cup=\E=%p1%' '%+%c%p2%' '%+%c, cuu1=^K, ed=\EY, el=\ET,
        home=\E=^A^A, hpa=\E]%p1%' '%+%c, ht=^I,
        if=/usr/local/ncurses/share/tabset/stdcrt, ind=\n,
        invis@, kbs=^H, kcub1=^H, kcud1=\n, kcuf1=^L, kcuu1=^K,
        kf0=^AI\r, kf1=^A@\r, kf2=^AA\r, kf3=^AB\r, kf4=^AC\r,
        kf5=^AD\r, kf6=^AE\r, kf7=^AF\r, kf8=^AG\r, kf9=^AH\r,
        khome=^^, rev=\EG4, rmso=\EG0, rmul=\EG0, sgr0=\EG0,
        smso=\EG4, smul=\EG8, vpa=\E[%p1%' '%+%c,
> 
> It turns out that, for all ncurses apps, with TERM=tvi910 I get a bunch of
> spaces being printed all the time, instead of optimized cursor movement.  I
> tried the same configuration on Debian 13 (trixie) as well as arch, and
> these work fine.  So I started to suspect the issue is something specific
> to the configure options used by Slackware.  I tested some other terminal
> types, vt100 and adm3a, and they seem to be unaffected.
> 
> I have written a trivial test program here:
> https://github.com/palazzol/ncurses_test
> And, I think I have narrowed it down to the configure option
> --enable-wmc-glitch option, which Slackware uses.  It seems like this

    --enable-xmc-glitch
        Compile-in support experimental xmc (magic cookie) code.
                           ^^^^^^^^^^^^

> causes the bad behavior with this terminal type.  If I rebuild ncurses
> without that, everything works fine.
> 
> Is this kind of dramatic failure expected when using that option?  I see it
> is marked as "experimental".  I'm honestly not sure if my trace has
> captured the root cause yet, but you can see that the test program
> generates <100 bytes when working properly, or >2K bytes when not.

I'd expect xmc-glitch to do "something" if there were video attributes,
and otherwise not much (and your example doesn't do that), so it sounds
like code rot which I can probably fix.  It's been a long time since that
feature was changed - from trying to get some clone of hpterm to run :-(

-- 
Thomas E. Dickey <[email protected]>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature

Reply via email to