Updated the workflow verify-pages.yml to include gelatyx being installed as per pages.yml

I pushed the workflow fix as 41ee60c; thanks!

For the main thrust of this PR: I think having multiple previews at once for the same scheme is probably overkill. What I've been idly thinking about was having the asciicast that we play cycle through a handful of different screens every few seconds. Having them animate by default is probably irritating so I would propose:

• The initial screen shows the current screen shot table, paused, but the last line says "Press play to see more previews"
• We have one or two other representative screenshots added to the ascii cast but separate say 3 seconds for the first one, then 10 or maybe 30 seconds apart for any remaining items.

The timing is easy to play with: the 0.0 in the data = json.dumps([0.0, "o", screen]) is the time (relative to start of playback) at which that output should be shown.

What do you think?

Ahhh #41ee60c lol no wonder it was bitching at me about cherry pickin's lol

I like it. Having them stacked on each other did seem like a bit too much but it opened a dialogue...

I like the idea of having one more ansi cap for previews... DO you have any sugg's on what would be best?

• A common utility ls --color? Maybe with grc{,-rs}(colorizer)?
• THe p10k config wizard where it shows multiple p rompts on screen?
• Multiple prompt themes/utils separated by a few lines (starship, p10k, spaceship, zinc, ohmyposh)?
• A utility with high screen refreshes that works off the default color scheme that we just trim down to 1 or 2 refreshes?
• Neovim with a base16 or 8/4-bit theme?
• A super busy bigger full-window preview of a tmux session and all those in one?

That is wezterm with terafox scheme, all panes are using it in base16 indexed coloring...

My preference is that we don't exceed the current 80x24 for a given preview; we can't resize the asciicast dynamically and I think larger screens can be overwhelming and overly information dense.

I think showing vim/nvim may be slightly disingenuous unless it is running with no defaults/no color schemes loaded, because I think almost everyone has their own thoughts on which colors go where, and I don't think there is a "standard" "just use the terminal colors" scheme. My own personal vim color scheme takes care to use the terminal palette based on the typical ANSI color hues, but it is again my preference.

https://terminal.sexy/ has a number of templates that I think are potentially interesting; looks like the sources for those are in https://github.com/stayradiated/terminal.sexy/tree/master/templates/vim/vivify but they'd need some processing to colorize them, which gets into the same subjective colorization issue as vim color schemes.

Similarly, I don't think things that target base16 for their output are good for non-base16: base16 doesn't use all 16 of its colors in terminal schemes, so you're losing out on a number of palette entries and won't be able to see the full range of the scheme's palette.

I think the most useful previews will be those that show the palette without "promising" how a particular app might look, with a few that show colors in apps that everyone uses but for which very few people customize the colors.

Sorry I wrote a memoir hopefully they publish my book here...

Similarly, I don't think things that target base16 for their output are good for non-base16: base16 doesn't use all 16 of its colors in terminal schemes, so you're losing out on a number of palette entries and won't be able to see the full range of the scheme's palette.

Just so I am clear and we are on the same page... When I say base16, I am not referring to the base16 scheme sets... I am refering to the base 16 colors using the 8 named ansi colors+bright, or the 0-15 indexed ansicolors (using this tool.. the iso 8 color, or 256-color ansicolors subset) shell color picker

I think the most useful previews will be those that show the palette without "promising" how a particular app might look, with a few that show colors in apps that everyone uses but for which very few people customize the colors.

I agree, I never want to gurantee or promise people stuff and now be married to making it work/look that way but the reason I am using base 16 or mentioning that in the preview is that they are indeed always guaranteed to be from the terminal's specified color scheme and is actually promised to look that way given the theme being truely base16 (0-15idx or ansinamed). The 16-232 indexes are 666 rgb that gradiate and are not guranteed to be part of the base 16, nor are they even generated or relate to the base 16. The 232-254 are greyscale. While the color schemes allow for setting the indexed colors they are seldom used, but when we say the base16 color scheme will look X with Y color scheme, it will actually look X when used with Y color scheme (sans opacity or hsb configs).
I can make the screenshot I posted previously update and use every color scheme's coloring. Those all use the original 16 indexed/named colors.

terminal.sexy has a number of templates that I think are potentially interesting; looks like the sources for those are in https://github.com/stayradiated/terminal.sexy/tree/master/templates/vim/vivify but they'd need some processing to colorize them, which gets into the same subjective colorization issue as vim color schemes.

We could actually use those quite easily using a base 16 type scheme / inline source editor. And/or we could capture the coloring info using bat --syntax base16{,-256}.

bat --list-themes you will see there is base16 and base16-256. Remember those are not related to the base16 theme set. They are only referring to using the original 4-bit ansicolors. From the list themes you can see those two syntax themes use the color scheme from the terminal, when the other named styles are completely different since they specify true color 888. Either way, that means that you could even include bat as part of the workflow to generate the output we need given a few source docs to have it style?

My preference is that we don't exceed the current 80x24 for a given preview;

When mentioning this I was thinking of a separate page that expanded to show more content at one shot/glance/viewport.

we can't resize the asciicast dynamically and I think larger screens can be overwhelming and overly information dense.

It also would not be too difficult to allow there be dynamic changes to asciinema player... We could offer a toolbar/dropdown or something that can change the preview content. This would also allow us to lighten and trim the size of the color scheme previews.

Currently you are generating base64 data for every style. We could update that to only encode the scheme color info, then the actual preview content could just be injected once for each diff content piece or loaded via ajax. We could also make it so that the preview is not loaded until the content scrolls into view or the content to preview is chosen .

I think showing vim/nvim may be slightly disingenuous unless it is running with no defaults/no color schemes loaded, because I think almost everyone has their own thoughts on which colors go where,

I guess I feel that way about those palette bars / color scripts that only print out the base 16 colors for BG of the other colors overlaid on top of them. That seems quite disingenuous because all those other colors have nothng to do with the color scheme usually.

and I don't think there is a "standard" "just use the terminal colors" scheme.

There actually is a scheme that does this. There is also one called Xresources that uses the 16 Xresources colors you can define which would work the same way almost...

Either way I am open to anything. Just my thoughts. I am not looking to place any work or burden on you, these would be somethiing I would work on given your blessing and guidance and sugg's.