-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Dokuwiki output: List elements with double line breaks fall back to HTML #7413
Comments
Semantically, a paragraph with internal hard line breaks is different from two paragraphs. So the output you're recommending would change the meaning. |
Please note that the use of HTML in DokuWiki is strongly discouraged since DokuWiki v2023-04-04 "Jack Jackrum":
|
@xrat that is good to know. What we should probably do is make dokuwiki output sensitive to the However, this would require finding some sensible alternative to use in lists with complex block-level content. Is there anything in current dokuwiki that would be the equivalent of, for example, the markdown list item
Any pandoc writer has to render this somehow. Currently we fall back to raw HTML in such cases for dokuwiki. What is the alternative? |
No, not in core DokuWiki without syntax extensions/plugins. Cf. wiki:syntax [DokuWiki]. There is even a FAQ "Multiline List Items" in faq:lists [DokuWiki]: "The list syntax expects you to put each item in a single line". The following DokuWiki extensions/plugins are worth mentioning in this context:
To somewhat illustrate the situation, here are best effort renditions of your example except for the fact that I am using a 2-line blockquote: Core DokuWiki list syntax (all on 1 line with the exception of
which is rendered as <li class="level1 node"><div class="li"> this is a paragraph.<br>
<br>
another.<br>
<br>
> and a<br>
> block quote<br>
<br>
<pre class="code ruby"> and.some.code()</pre>
</div>
<ol>
<li class="level2"><div class="li"> and a nested list here</div></li>
<li class="level2"><div class="li"> with more items</div></li>
</ol>
</li> DokuWiki list syntax with wrap extension:
renders as <li class="level1"><div class="li"> this is a paragraph <br>
<div class="plugin_wrap">
<p>another</p>
<blockquote><div class="no">
and a<br>
block quote</div></blockquote>
<pre class="code ruby"> and.some.code()</pre>
<ol>
<li class="level1"><div class="li"> and a nested list here</div></li>
<li class="level1"><div class="li"> with more items</div></li>
</ol>
</div></div>
</li> |
The WRAP extension looks like it might be the best approach. Is that in wide use? |
DokuWiki collects voluntary statistics. According to this data the wrap extension is actually the most popular one. Cf. the table at plugins [DokuWiki] accessed just now (not counting the "upgrade" plugin for obvious reasons) |
One more question about WRAP. Can you instead do this?
That would be more uniform and easier to generate. |
I fully agree. And I have good news: It works. <ol>
<li class="level1"><div class="li"> <div class="plugin_wrap">
<p>this is a paragraph</p>
<p>another</p>
<blockquote><div class="no">
and a<br>
block quote</div></blockquote>
<pre class="code ruby"> and.some.code()</pre>
<ol>
<li class="level1"><div class="li"> and a nested list here</div></li>
<li class="level1"><div class="li"> with more items</div></li>
</ol>
</div></div>
</li>
</ol> (I've removed some NLs to make the code more compact, e.g. before |
Can it handle nested cases, where you have another |
Yes. |
Consider the following Pandoc Markdown:
Converting it with
pandoc file.txt -f markdown -t dokuwiki -o output.txt
results in
which is overly complicated, because Dokuwiki's docs state that the following is recommended in this case (resulting in an output very similar to Pandoc's markdown):
which renders like this in native Dokuwiki:
Since allowing HTML in Dokuwiki is a potential security problem, I'd expect Pandoc to try to convert as much as possible without relying on native HTML tags.
Note: The file I'm originally starting from is a LaTeX file with a double line break in a list item, but the issue is reproducible with Pandoc's markdown format as well.
Pandoc version:
The text was updated successfully, but these errors were encountered: