Closed hernot closed 2 years ago
Thanks. I am traveling right now and will look at it in about 10 days when I return.
It will be helpful if you could submit a pull request with only the required changes (and not stylistic changes like changing the indentation in examples, etc.)
I already noticed my self, i wil squash out the stylistic stuff
I am merging the changed CSS file.
Regarding replacing pre-wrap
with pre-line
, I don't think that pre-line
is more appeasing. IIUC (e.g., this example) pre-line
collapses all inter-word space to a single space, which can is not desirable when formatting code.
I'm with you the even better solution would be to figure what configuration on <floatcontent>
or one of its parents makes <verbatim line>
and thus vimtyping tags behave different. What i do observe is that number of parent tags and oder of tags is different such that css style set by <vimtyping>
seems to be removed again after <verbatim line>
or some other setting which also invervenes with whitespace causes whitepsace settings beeing ignored inside <floatcontent>
I have not enough knowledge upon web programming or css to figure the reason or even understand what happens and what style settings to explicitly disable or revert to ensure <vimtyping>
environment behaves identical inside <floatcontent>
and outside where it is typeset correctly.
The strange thing is that white-space:pre-wrap
was behaving differently when exporting with context versions<2022. On context version >= 2022 it can be converted back to pre-wrap again. Cause, amongst others, how line numbers are exported to html has changed. In older version line numbers were inserted as plain text before any other text and tag in the line. The 2022 versions now wrap the line numbers in <div></div>
tags with their own class and css style which solves a lot of the hassle. For older versions if whitespace should be obeyed as typeset and wrapping should only occur on \n
plain pre
without wrap could be used instead of pre-line
. So not sure if from within vimtyping code it would be possible to identify context version and enforce on contex version < 2022 white-space:pre-line
or plain white-space:pre
and for context version >= 2022 use white-space=pre-wrap
. In any case display=block
has to be reenforced on vimtyping when <verbatimline>
is typeset within <floatcontent>
for now.
Alternatively use white-space:pre-wrap
only and add a note to README-vim.md
indicating that vimtyping contentent placed within float environment is only properly displaced on html/xml/xhtml exported by context version 2022 and later. On older versions placing vimtyping content inside float will yield distorted looking outputs.
I assume that most context user will be using a reasonably up to date context distribution. So, if it is working with the latest version, then it is okay.
So should i create a new pull request reverting to pre-wrap
and adding the note in README-vim.md or will you simply do on next release?
The submitted pull request did not change pre-wrap, so there is no need to change it.
I don't want to change the README, because I think that it will be confusing to a new user.
this is just a small side in the issue related i'm already persuing for some time with the help of hans and others. Details see #64 . In preparation thereof i rerun the export tests and figured that line wrapping is left at where our last attempts have stopped. I gave it again a try on Firefox (99.0) and Google Chrome (Chromium 100.0.4896.60) on Linux Mint 20 and figured what to do to ensure linewrapping is proper when vimtyping environment is used standalone and withing floating environment. The result is this pullrequest
Note: Just noticed that update of context did not yield the latest version as expected but is stuck in 2020 version. Will update and rerun again with latest context. At least
context --version
tells me the following eventhough i rerun first-setup.shEdit Guess i have to also get the latest context standalone (see below) for work before as with it and the css fix in this pullrequest not just line wrapping is finally at least on the named browsers proper but also line numbers seem to be back in pdf and export.. Keep you posted on this and the other stuff