-
-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zsh p10k and fast syntax highlight base16 preview for docs #2286
base: main
Are you sure you want to change the base?
Conversation
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 timing is easy to play with: the 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?
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...
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 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).
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
When mentioning this I was thinking of a separate page that expanded to show more content at one shot/glance/viewport.
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 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.
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. |
the palette is great and all but not the greatest for showing the color usage in an actual use case. figured it would be nice to show the scheme in a real usage scenario
that's not the greatest scheme for preview but just ss'd the first ok looking oneupdated shot with terafox since you added their repo 😬
adds an extra asciipreview with a dump from a tmux pane with p10k prompt and output of
fast-theme -t base16
which is thezsh-users/F-sy-h
syntax highlight theme that uses indexed colors based off the term's configured color scheme