Xtask theme previews

[hirschenberger]

Add xtask to generate html previews for all themes. Requires the aha tool installed to convert ANSI sequences to HTML. aha should be available for your linux distribution of choice.

This is still WIP and needs some discussion how and where to integrate the previews to the docs.

fixes #3608

[archseer]

Do we need to have a preview doc though? The users can cycle over :theme completions and see how each theme would look like with their codebase

[hirschenberger]

Do we need to have a preview doc though? The users can cycle over :theme completions and see how each theme would look like with their codebase

see #3608 for the intention of this PR. There's a preview for all themes in the wiki, but they look different.

[pickfire]

I suggested this to @AlexanderBrevig in one of the pull requests but looks like you started work on it.

It's definitely good to be able to compare different themes on the same code, otherwise it looks different on different languages, one thing I think would be interesting is to be able to cover a wide range of syntax (maybe we need a language switcher for that), since later users would strive to make it look good on just the screenshots and not good on real use (missing some theming).

[hirschenberger]

We can use two nested loops: Over all languages (having a folder with some pretty code snippets) and all themes and pregenerate all previews and use some JS to switch languages on the docs.

Or we can create an interactive webapp, that generates the previews on-the-fly and also can provide the possibility to provide own snippets. But I assume that can't be hosted on github anymore.

[AlexanderBrevig]

I've been playing with doing this from github actions and publishing a wiki page with screenshots (from a headless wayland docker monstrosity). I must say that this path feels a lot more appealing to me. Makes sense to have the themes in the docs, and when it's just HTML there's no real size issues either.

EDIT: Would Asciinema be an alternative worth considering? Instead of aha? Same idea just a different technology for accomplishing the same goal.

[hirschenberger]

EDIT: Would Asciinema be an alternative worth considering? Instead of aha? Same idea just a different technology for accomplishing the same goal.

Asciinema seems to be tailored towards video creation for their own hosting platform. What would be the benefit using videos? Iterating all themes or all languages with one theme per video?

It seems to be easy to create asciinema files from the captured ANSI sequence but I see no benefit to static HTML files.

[AlexanderBrevig]

Asciinema seems to be tailored towards video creation for their own hosting platform. What would be the benefit using videos? Iterating all themes or all languages with one theme per video?

It seems to be easy to create asciinema files from the captured ANSI sequence but I see no benefit to static HTML files.

Asciinema saves to static text files, and easily embeddeble with their player. The way WezTerm does it has come up before.

[hirschenberger]

The way WezTerm does it has come up before.

I must say I don't really like using an external player just to show a single frame. I see no benefit to the current solution.

[AlexanderBrevig]

The way WezTerm does it has come up before.

I must say I don't really like using an external player just to show a single frame. I see no benefit to the current solution.

Sure :) I guess the benefit would be that we don't need to maintain workarounds to get rendering perfect. It would also mean that we could generate an actual sequence showing off menus, a few languages, and markdown.

There's also the question of whether we want to enforce an additional dependency from the environment for people running this command.

Keep in mind, I'm just thinking out loud here and have no real say in the matter.

[hirschenberger]

The way WezTerm does it has come up before.

I must say I don't really like using an external player just to show a single frame. I see no benefit to the current solution.

Sure :) I guess the benefit would be that we don't need to maintain workarounds to get rendering perfect. It would also mean that we could generate an actual sequence showing off menus, a few languages, and markdown.

There's also the question of whether we want to enforce an additional dependency from the environment for people running this command.

Keep in mind, I'm just thinking out loud here and have no real say in the matter.

I'm also not in the position to decide. Both approaches have their pros and cons. I try to summarize it, please correct me if I miss something.

HTML

• 👍🏼 No player needed to view, so offline capable
• 👍🏼 Already implemented as PoC
• 👎🏼 Needs thirdparty tool aha to generate the HTML locally
• 👎🏼 Can only generate static screenshots

Asciinema

• 👍🏼 No thirdparty tool needed to generate docs locally
• 👍🏼 Can generate clips and images.
• 👎🏼 Depends on thirdparty service provider (asciinema.org)
• 👎🏼 Must be online to view docs (themes), also locally generated.

[David-Else]

Having a built in command to export the current document to HTML with syntax highlighting would be fantastic.

Neovim's https://neovim.io/doc/user/syntax.html#:TOhtml command is broken for treesitter syntax highlighting. It would be great to have it in Helix, would be perfect to create syntax highlighted code blocks in blogs/documentation without using https://prismjs.com/, much cleaner.

4. Conversion to HTML				*2html.vim* *convert-to-HTML*

2html is not a [syntax](https://neovim.io/doc/user/syntax.html#syntax) file
itself, but a [script](https://neovim.io/doc/user/usr_41.html#script) that
converts the current [window](https://neovim.io/doc/user/windows.html#window)
into HTML. Vim opens a new [window](https://neovim.io/doc/user/
windows.html#window) in which [it](https://neovim.io/doc/user/motion.html#it)
builds the HTML file.

After you save the resulting file, you can view [it](https://neovim.io/doc/
user/motion.html#it) with any browser. The colors should be exactly the same
[as](https://neovim.io/doc/user/motion.html#as) you see them in Vim.  With |
[g:html_line_ids](https://neovim.io/doc/user/syntax.html#g:html_line_ids)|
you can jump to specific lines by adding (for example) #L123 or #123 to the
end of the URL in your browser's address [bar](https://neovim.io/doc/user/
motion.html#bar). And with |[g:html_dynamic_folds](https://neovim.io/doc/user/
syntax.html#g:html_dynamic_folds)| enabled, you can show or hide the text that
is folded in Vim.

You are not supposed to set the ['filetype'](https://neovim.io/doc/
user/options.html#'filetype') or ['syntax'](https://neovim.io/doc/user/
options.html#'syntax') option to "2html"! Source the [script](https://
neovim.io/doc/user/usr_41.html#script) to convert the current file:

[hirschenberger]

My initial Idea was to use the ansi-to-html crate to generate the HTML, but unfortunately it does not support the CUP (cursor position) code, so the output is garbage.

Another approach would be to add support for CUP to ansi-to-html and have a version without non-crate dependencies.

EDIT: here's a gist with the gruvbox theme example: https://gist.github.com/hirschenberger/794a80462d07fc93f75e1215720b1b60

[hirschenberger]

Having a built in command to export the current document to HTML with syntax highlighting would be fantastic.

This seems to be a different topic, as this PR does create a screenshot of the whole editor with code.

@David-Else Maybe it makes sense to open it's own issue for that?

[AlexanderBrevig]

• 👎🏼 Depends on thirdparty service provider (asciinema.org)
• 👎🏼 Must be online to view docs (themes), also locally generated.

We could vendor the player and host the recordings in our repo (much like the html, its just json instead).

👎🏻 ➡️ 👍🏻

[hirschenberger]

Ok, I'll create a PoC, let's see how it works with Asciinema

[AlexanderBrevig]

Ok, I'll create a PoC, let's see how it works with Asciinema

It may very well be that the maintainers like the HTTP route more. Keep in mind before spending time on this! I don't want you to feel like you've wasted time because of me. But if you do it for fun and profit, please let me know your experience.

I personally very much like the idea that the themes are documented - in a similar and comparable way - in the docs and not in the github wiki 👍🏻 😄

[hirschenberger]

Ok, pandora's box is open 🙈

I'm writing a asciinema preprocessor for mdbook for a tight integration from within markdown.

[the-mikedavis]

Converting from escape sequences to HTML is over-engineering it IMO. It should be possible to do this by building an SVG or HTML document manually by consuming the helix_core::syntax::Syntax::highlight_iter iterator. Tree-sitter-cli's highlight command does the same https://github.com/tree-sitter/tree-sitter/blob/67d13cf50b0b74f7037adec314a571bd68546ebf/highlight/src/lib.rs#L888

[hirschenberger]

Converting from escape sequences to HTML is over-engineering it IMO. It should be possible to do this by building an SVG or HTML document manually by consuming the helix_core::syntax::Syntax::highlight_iter iterator. Tree-sitter-cli's highlight command does the same https://github.com/tree-sitter/tree-sitter/blob/67d13cf50b0b74f7037adec314a571bd68546ebf/highlight/src/lib.rs#L888

But this would only create HTML of the code, not of the editor itself, right? I'd like it more if you also see how the editor looks like with the current theme.

IMHO it's also more KISS to use an established and well-tested approach (ANSI -> HTML) that asciinema, aha, and others already have, than fiddling around with handcrafting HTML.

[archseer]

There's a preview for all themes in the wiki, but they look different.

Yeah, but we could remove that page altogether? It served a purpose when themes didn't have a live preview, but now you can just tab through dozens of themes and see how they'd look on your code.

[hirschenberger]

There's a preview for all themes in the wiki, but they look different.

Yeah, but we could remove that page altogether? It served a purpose when themes didn't have a live preview, but now you can just tab through dozens of themes and see how they'd look on your code.

So you want to say that PR and issue is unnecessary?

[archseer]

I'm just trying to gauge if this is desirable or not. If users want a html doc with these then that's okay, I'm just saying personally: I preview these in the editor now.

[pickfire]

One benefit of doing this instead of doing it in the docs is the code snippet shown in the example may be able to utilize more colors given that it is usually tweaked to give users impression of the theme in general, and doing it at current code may not be able to utilize more colors which one single screen is able to see on a complex project.

But other than that I don't really see much benefit over previewing it locally, the local preview even have the ability to filter like by light theme (using search) which I doubt we are going to add it to the html theme preview.

[pascalkuthe]

I don't see usadding this to core and this PR has gone stale so I am going to close this. Thank you for contributing!