search

adityam / filter

ConTeXt module to process contents of a start-stop environment through an external program
47 stars 10 forks source link

\SYN command causes fuzzy paragraph warnings in xmlexporter #64

Open hernot opened 2 years ago

hernot commented 2 years ago

While once again working on generating an epub version of my lecture notes i noticed fuzzy paragraph warnings when turning on export trackers. Searching on the mailing list i found the following thread. Inspired by this and remembering a suggestion by Hans i changed all my \paragraph, \section etc. to their \startchapter, \stopchapter etc. pairs. The same i did with all the \place<float> commands. This had the effect that the number of fuzzy paragraphs and improper content levels became less an the number of pages exported to html,xhtml and xml doubled.

Encouraged by this i investigated further and identified some further suspects. One thereof is the \SYN command. which is synonymous for \syntaxgroup. Therefore I decided to dedicate some of my time to test if replacing \syntaxgroup command by a pair of \starsyntaxgroup \stopsyntaxgroup and \SYN by \BSYN, \ESYN pairs. Thereby I would need some advice or support in writing proper ConTeXt TeX code. Especially how to properly represent lines 99-100 and 104 in the \startsyntaxgroup and \stopsyntaxgroup commands.

As soon as having first results and insights I either will post here or open a pull-request whichever is most suitable.

adityam commented 2 years ago

Can you post a minimal example which shows the warnings triggered by syntax highlighting?

hernot commented 2 years ago

Here the log generated running context --mode=dev-vim --trackers=export* tests/vim/41-export.tex

41-export.log

And here the log generated running

context --mode=dev-vim --trackers=export* tests/vim/43-export-float.tex

43-export-float.log

As you can see done with the latest context standalone (ConTeXt ver: 2022.04.15 20:13 MKIV fmt: 2022.4.19 int: english/english). So things are already a lot less messy and worrying than with older versions. But still too much to not make them suspect to beeing the cause to confuse the exporter and cause the exporter to mixup levels. And yes there is also a similar issue in \startsection and alike ocmmands. But that is something to be reported on the mailing list and/or context repos.

adityam commented 2 years ago

Can you test with fuzzy-par branch to see if that fixes the warning at your end?

hernot commented 2 years ago

Hm my context is per default set to mkiv. Adding \dotagsetparcounter in t-syntax-highlighting.tex the fuzzi paragraph warnings related to vimtyping are gone but on the long document i do get after nearly every code snipped inline and environment a <break></break> tag which makes text and code examples even more distorted looking. Which i do not when \dotagsetparcounter is not present on line start command. Not sure if that is cause \dotagsetparcounter behaves differently for mkiv and mklx (not sure how to run tests in both luatex and lmtx).

likely not or indirect related

Adding for exampe /BTEX \somelin[code:test_btex_etex]/ETEX to the examples and setting escape=command than the lines where someline refers are followed by an empty line which seemst to be caused by wrapping. Looking into the html code i do see that <div class=reference ...> </div> is output twice either as cause of fuzzy paragraph or beeing an additional cause for fuzzy paragraph.

Further lines with empty /SYNBOL{}/SYNEOL{} are removed and their line numbers are appended below the last non empty line. Modifiying 2context.vim to output /SYNBOL{] /SYNEOL{} instead makes the empty lines appear where the are in the sources with their proper line number.

adityam commented 2 years ago

Thanks for testing. I'll test other ways on how to fix this. I was primarily testing with LMTX. You can run context --luatex to run mkiv and context --luametatex to run LMTX.

Regarding your other question, it may be easier to create a separate issue for it. If you already have a fix for 2context, please submit a pull request and I'll be happy to merge it.

hernot commented 2 years ago

I guess, i will wait with pull-requests until the main is solved. To ensure that none is indirectly dependent on the main. Especially i want to wait for the empty lines if they would happen to at least be partially solved with the main. The ref issue is rather likely an exporter thingy as the context default.css do not contain any formatting rules for reference class. Only the template and there the settings seem to be the defaults for any remaining tag.