Package: ncurses
Version: 5.7+20100313-2
Severity: normal

Hello,

ncureses seems to reset my palette (under 'linux' terminal) when
refresh() is preceded by endwin() (e.g. mutt calls it that way).

Attached program illustrates the issue. If called with no arguments -
the palette is fine, but call it with any argument and palette is reset
to terminal's defaults.

Regards,

This sounds like something I noticed last fall:

091003
**      test/ncurses accepts a 'm' menu entry to run other tests using the
         current colors.  If I run a color test 'b' or 'c' then
         on return the color samples are not filled in any longer.

A trace of your program shows me that ncurses is resetting the colors
when returning from shell-mode (after the endwin is called).

(will see - thanks)

hmm - this was different from my to-do item.

The particular feature we're talking about here was added

20020928 pre-release
        + restore original color definitions in endwin() if init_color() was
          used, and resume those colors on the next doupdate() or refresh()
          (report by Tomasz Wasiak <tjwasiak@komputom.com.pl>).

Specially, that's using the "oc" (orig_colors) capability in the "linux"
terminal description.  If the terminal description contains that, ncurses
will use it.  (The advantages of keeping it seem to outweigh the disadvantage).

There is no way for ncurses to tell if there was a change to the color
palette between the endwin/refresh calls.

The "linux-basic" terminal description does not have that feature.
So you could set TERM to "linux-basic".

Presumably you are setting the palette using an escape sequence.
It's been a while since I looked, but I thought I recalled that
setterm had an option for setting the palette directly.

man console_ioctl does show this:

       PIO_CMAP
              Change the default  text-mode  color  map.   argp  points  to  a
              48-byte array which contains, in order, the Red, Green, and Blue
              values for the 16 available screen colors: 0 is off, and 255  is
              full  intensity.   The default colors are, in order: black, dark
              red, dark green, brown, dark blue, dark purple, dark cyan, light
              grey,  dark grey, bright red, bright green, yellow, bright blue,
              bright purple, bright cyan and white.  (Since 1.3.3.)

But I do not see a use of this in the (package util-linux) setterm code.

hmm - this was different from my to-do item.

The particular feature we're talking about here was added

20020928 pre-release
        + restore original color definitions in endwin() if init_color() was
          used, and resume those colors on the next doupdate() or refresh()
          (report by Tomasz Wasiak <tjwasiak@komputom.com.pl>).

Specially, that's using the "oc" (orig_colors) capability in the "linux"
terminal description.  If the terminal description contains that, ncurses
will use it.  (The advantages of keeping it seem to outweigh the disadvantage).

There is no way for ncurses to tell if there was a change to the color
palette between the endwin/refresh calls.

The "linux-basic" terminal description does not have that feature.
So you could set TERM to "linux-basic".

Presumably you are setting the palette using an escape sequence.
It's been a while since I looked, but I thought I recalled that
setterm had an option for setting the palette directly.

man console_ioctl does show this:

       PIO_CMAP
              Change the default  text-mode  color  map.   argp  points  to  a
              48-byte array which contains, in order, the Red, Green, and Blue
              values for the 16 available screen colors: 0 is off, and 255  is
              full  intensity.   The default colors are, in order: black, dark
              red, dark green, brown, dark blue, dark purple, dark cyan, light
              grey,  dark grey, bright red, bright green, yellow, bright blue,
              bright purple, bright cyan and white.  (Since 1.3.3.)

But I do not see a use of this in the (package util-linux) setterm code.