Add support for 'default' fg/bg colors in ScreenBuffer about terminal-kit

[cronvel]

@samizdatco In fact, there IS a call to ScreenBuffer#fill() at instanciation, unless the 'noFill' option is passed to ScreenBuffer.create(). Without that initial .fill(), the internal Buffer instance is not filled, and is left in the state of it was after Buffer.allocUnsafe(): this option is usually not recommended except if you call .fill() immediately with your own option, or if you draw immediately the whole surface (e.g. with other screenBuffers, with ScreenBuffer#put(), etc). In case you don't, your screenBuffer is simply filled with garbage.

Also, the transparency option does not works when drawing directly to a terminal. You know, you just can't get informations about the content of a terminal, so it's impossible to implement transparency. And it's impossible to guess the actual background color for a given cell, neither the actual character displayed.

Transparency only works when drawing a screenBuffer into another screenBuffer.

Basically, what you want to achieve should be done with a call to ScreenBuffer#fill() with the correct color, if you can guess it.

Using the screenBuffer is like opening a window in your window manager, the new window doesn't know what is below, and just start by clearing itself.

[samizdatco]

That does make sense. In my case though I'm not trying to avoid filling the screenbuffer, it's more that I'm not sure how to set the fg & bg colors to a pair of specific values. What I'd like to do is use the 'default text' and 'default background' colors for the terminal.

From the Wikipedia page on ANSI Escape Codes, it's this pair of values in particular that I'm after:

Is there currently a way to tell ScreenBuffer to use these colors (rather than the ones defined with codes 30-38 and 40-48)?

[cronvel]

I'm afraid, but if that default color is not one of the 256 color palette, it wont be possible.
The ScreenBuffer uses one byte to code the BG color index and one byte to store the FG color index, there is no room for a 257th index.

Usually, the default color is either black or white or a shade of black/white, inside the 8 ANSI color palette or the 16 aixterm color palette. But some terminals allow any true color as the default color even if it is not part of the 256 color palette.

I understand that it can be frustrating, I need to think about a solution...

[samizdatco]

I took a swing at adding the feature here: #31 . In my limited testing (and with my limited understanding of terminal-kit's internals) it seems like it's working.

It wouldn't surprise me at all if there are bugs in the way transparency and blending are handled though since I don't really have a handle on what's happening in those methods. That said, the spaceship.js demo seems to be working identically, so to the extent that it exercises all of ScreenBuffer's features, that's a good sign...

[cronvel]

@samizdatco Thanks for your contribution, but unfortunately I was already working on that.
I'm trying to avoid a SemVer Major change and aim for a backward compatible change.

[cronvel]

@samizdatco it's done. It landed on v1.10.0.

You can do it using the new attr options {defaultColor: true, bgDefaultColor: true }.
This is also the default options for .fill() and at ScreenBuffer/ScreenBufferHD creation.
Tell me if that's working for you.

[samizdatco]

The code is looking good! I've found one place where the default colors are 'leaking' outside of their defined areas though. See #32

[cronvel]

@samizdatco Thanks, it's merged. I fixed ScreenBufferHD too.