Export support for vimtyping

[hernot]

OK finally the export works outside floats if linenumbering is off or numberlocation is default or left. Inside floats all lines are still squashed into one line as if float class or float content class makes browsers ignore css settings for vimtyping and verbatimline. But no idea. Requires further check. Linenumbering is broken in general. if numberlocation set to right than each line is put into its own vimtyping div. And inside floats first number is before vimtyping block and rest is after. Not sure what the reason is needs further checks.

Naming of vimtiypings not yet checked if names are all uppercase.

My branch copy was not rebased to latests on upstream. I just cherrypicked t-filter.tex and t-vim.tex and corresponding test from base/export-2 and checked them out into my copy to make insync.

[adityam]

Thanks. I'll take a look.

Note that there is no point in added lua code to .mkii file. MkII uses pdftex as the engine, so the lua code will not work.

[hernot]

Ok what i have found related to floats is that inside floats the whitespace inbetween <verbatimline> tags and <div class=verbatimline> tags is still removed while without floats it is preserved in output. By manually adding whitespace (*) to html and for better readability placing each <verbatimline> on its separate source line formatting of <vimtyping> content suddenly appears as expected. And comparing tests/vim/37.tex to tests/vim/38.tex which just differ in that the latter is enclosing within floats the only true difference is exactly this kind of whithespace.

(*) a single whitespace char following the newline is sufficient

That could be also the reason for line numbering with numberlocation=left or default setting that first linenumber is placed before <vimtyping> tag and the rest following it.

Have no idea how to get ridd of splitting into several <vimtyping> sections for numberlocation=right.

[hernot]

Note that there is no point in added lua code to .mkii file. MkII uses pdftex as the engine, so the lua code will not work.

Oh sorry i missed that. Sure. I wanted anyway to mention that i have no mkii installatoin here and thus have no idea whether support for export makes any sense. Please remove form mkii files anything export related making no sense to mkii unless you haven't done anyway already.

[hernot]

As i went through open issues just for sake of completeness and to nothing miss i think this pullrequest or the final release based upon it would close #3 #31 and rendered pullrequest #34 obsolete which i already closed.

[adityam]

Thanks for cleaning up the old issues!

I have merged the changes into a new branch export-3. I still need to think about the best way to do this.

Firstly, the bug with numberlocation=right should be fixed in the new release. We'll look into numbering with floats next.

1. The current code uses \doifmode{*export}{...}. This means that \setupbackend[export=yes] must happen before loading the vim module. It should be possible to do this by adding code to \everyexport tokens.

2. I am thinking of creating a high-level interface for including css as follows.

   \setupvimtyping[cssfile=default|auto|name]

   where default includes pre-written CSS files which are included (we need to create these); auto means auto-generated CSS files based on your code, and any other option includes the file specified by that name.

3. I don't think that parsing of command key is a good idea. There is so many different ways this could be configured, that simply checking for a few pre-specified names will not work.

[hernot]

Firstly, the bug with numberlocation=right should be fixed in the new release. We'll look into numbering with floats next.

Oh! did I miss a ConTeXt release or is release still pending. The one I tested on is: ConTeXt Process Management 1.03 current version 2020.01.30 14:13

1. The current code uses `\doifmode{*export}{...}`. This means that `\setupbackend[export=yes]` must happen before loading the `vim` module. It should be possible to do this by adding code to `\everyexport` tokens.

There you are more experienced which is the better and proper solution. I just took what i found in the docs. If \everyexport is the right than it should be changed if it has the same effect that css is only included or created if export to html, xhtml and xml is active otherwise I do not see any reason for doing.

2. I am thinking of creating a high-level interface for including css as follows.

\setupvimtyping[cssfile=default|auto|name]

where default includes pre-written CSS files which are included (we need to create these); auto means auto-generated CSS files based on your code, and any other option includes the file specified by that name.

For the default (pre-written) I'd suggest to just pick a few syntaxgroups for styling with a fixed style for each to cover major syntax groups or at least most important thereof and ignore the rest which could not be present in all languages supported by vim. As a starting template the ones currently autocreated could be used. Cleaning up a few things. Limiting the styling to subitmes of vimtyping[detail=colorscheme] should be kept in any case to avoid side effects when users also utilize typing environment and others.

1. I don't think that parsing of `command` key is a good idea. There is so many different ways this could be configured, that simply checking for a few pre-specified names will not work.

Hm I fear that CSS will be the limiting factor here:

• commands which have a corresponding formatting in css must be mapped to one or serveral distinct style attributes to achieve the desired formatting. This requires some sort of mechanism to achieve proper mapping between commands and attributes how ever this is best achieved. Current solution solves this for a very limited set with simple parsing.

• command which have no corresponding formattion have to be constructed using additional tags which decorate either the syntaxgroup as a whole or its content to achieve the appropriate styling.

• any command for which the two aforementioned possibilities is not a solution have to be dropped.

I can check what attributes are offered by CSS for div tags and what additional styling beyond font and color they would offer. And based upon this it than should be decided if and which should be suported and how they could be mapped to content of command parameter.

[adityam]

There is a new release typically every couple of days. There was one released yesterday and a new update today which fixes the export of linenumbers of the right.

[hernot]

Opened new issue #39 for further discussion upon command parameter, if and how to map it to CSS.