If a listitem has no content, then parsing that empty listitem back
into syntax caused a crash. This is now fixed, prevented and tested.
The trade-off is that syntax
* <code>foo</code>
has now an extra linebreak in front of the code block.
See sentry issues WIKI-A1, WIKI-9G, WIKI-A2, WIKI-9H, WIKI-A0 ...
These macros have no visual representation in the xhtml rendered by
DokuWiki and thus should not be rendered in the prosemirror editor
either.
Attaching this to the root not seems to be cleanest approach. However,
this has some challenges, because by default the attributes on the doc
node cannot be edited because, currently, prosemirror transformations
only apply to the _content_ of the document. However, marijn
indicated[0] that it might be worth adding a step for this to the
official packages.
We are here using a custom step that was provided in another thread[1]
on the official form that does exactly that: setting attributes on the
doc node.
However, these macros make only sense on a top-level page, not in
footnotes. Thus, they are removed from that schema. Something similar
would likely have to be done for a schema for the wrap-plugin or other
similar plugins.
Also, I think checkboxes are the best way to go for representing
toggeling of options. Thus, I added them with a render function and
hide/show them during the update() step. The background is that the
render function is only run during the initialisation and later only
updated via the update() method. See the MenuView class and the called
methods in MenuItem.
Further, the macros themselves are not rendered in the HTML, but the
spaces and linebreaks may still generate instructions for an more or
less empty paragraph. To ensure consistent spacing in the syntax
between the blocks, I've added the rtrim call in the RootNode. Thus
all blocks in the syntax should now always be separated by exactly one
empty line.
[0] https://discuss.prosemirror.net/t/meta-data-nodes/1163/6
[1] https://discuss.prosemirror.net/t/changing-doc-attrs/784/17
This fixes two things:
1. DokuWiki allows for some blocks in table cells, i.e. protected and
substitution. Since we cannot mix blocks and inline content in
Prosemirror, we have to allow only block-nodes within table cells and
hence must start with a paragraph to support simple text.
When allowing for paragraphs we have to guard our trimming statement
because `ltrim(null)` is apparently an empty string.
2. The splitCell command from prosemirror-tables module implicitly expects to
be called from within a block element in a table cell. Because their
cellWrapping utlility function starts at looking for the table cell at
`pos.depth - 1` which is the table row if the cell only contains inline
content. See also ProseMirror/prosemirror-tables#59 for this.
The previous approach didn't work.
Using a list_paragraph inside of the li failed, because then Prosemirror
would no longer wrap ordinary paragraphs in list items.
Using an ordinary paragraph inside of a list item wouldn't work because
than splitting list items with the Enter-key breaks because it only
splits list items if one is in the direct descendant of the list_item.
Hence, using paragraphs directly in the list item and fixing styles via
css.
This fixes the problem that headlines and quoting was possible in list
nodes. To achieve this we build list nodes closer to how they are in
dokuwiki. They must now contain one list_content node and may contain
one bullet_list or ordered_list node. The list_content node may contain
a list_paragraph (it's just like an ordinary paragraph, except that it
is rendered in `<div>` instead of `<p>` tags to prevent extra styling)
or nodes from the group protected_block or substitution_block. The
groups are created analogous to the PARSER_MODES in DokuWiki, except
that we have to differentiate between block and inline nodes.
This should fix two more items mentioned in #28
Currently, they are treated as common text. Later we should add an
toolbar button, actually render them as images and add an input macro
that replaces the typed text with the image.
As with parsing, lots of link rendering as much overlap between the
different link types. Moving this to their respective parser classes
bundles related code at one place.
The link nodes have large parts of identical functionality so it makes
sense to extract a common parent class.
This also extended the ImageNode class to correctly implement the
InlineNode interface as it is an inline node,
Now parsing for plugins works. Also, plugin nodes can now only contain a
single text node, which means that marks can now only be applied to the
entire node instead incorrectly to parts of it.
This is very much not done yet, but at least it doesn't break anymore
when editing a page with footnotes. However footnotes cannot properly be
removed or added and they do appear inline.
