Closed link2xt closed 6 years ago
I am not sure what exact markup rules are, but here is a testcase I propose:
- Bullet list start
term :: first definition paragraph start
first definition paragraph continuation
second definition paragraph
paragraph outside definition but inside bullet list
I placed definition list inside bullet list to avoid dealing with Text::Amuse requirement to indent definition list with one space and test that paragraphs don't turn into blockquotes.
Also, how much should the second paragraph be indented to be part of the definition? Is one space enough?
Looks like formal rules should be as follows:
All list items (bullet, ordered or definition) start with list marker (" - ", " 1. ", " term :: "), followed by paragraph that is not required to be indented.
Then, any list item continuations are separated by one blank line and should be indented by marker width. For definition lists, marker width is always considered to be 1.
Two blank lines finish the list.
Alexander notifications@github.com writes:
In
desc-lists.muse
there is a line which says "Back to item", but HTML result is wrong, this line appears to be inside definition list: https://github.com/melmothx/text-amuse/blob/4c2c74d9abf334dc8cd9a6dd9e9d6075fe8e6ab4/t/testfiles/desc-lists.exp.html#L117
It looks like that file has been that way since it was installed in the tree...
Emacs Muse handles this correctly, except that it considers this line to be a blockquote, but it is another problem: it should look at relative indentation to detect blockquotes.
Well, I don't see much point in allowing blockquotes inside lists (beside blowing up the whole thing). Ok that we could reach arbitrary complexity, but in that case a lightweight markup is not the right tool.
Anyway I pinpointed the problem.
We have such case
item
item
term :: description
term continuation
item continuation.
The problem is that the ordered list is seen having indentation 4. Same as the description list. So when it encounter "item continuation", it thinks it belongs to the term.
I'll see if I can fix it properly or if the fix breaks more stuff than it actually fixes.
Indenting another 2 spaces the nested description list fixes the issue, from an editor point of view.
-- Marco
Alexander notifications@github.com writes:
Looks like formal rules should be as follows:
All list items (bullet, ordered or definition) start with list marker (" - ", " 1. ", " term :: ", followed by paragraph that is not required to be indented.
Then, any list item continuations are separated by one blank line and should be indented by marker width. For definition lists, marker width is always considered to be 1.
Two blank lines finish the list.
Mhm, I thought we already discussed the blank lines issue. I don't think they should be relevant. Also, with the lists obeying the index, what's the semantic of a list that stops and continue again?
-- Marco
Actually, please disregard the indentation 4 issue. Something else is going on. I need to dig.
This is probably fixed. The implementation is a bit more relaxed than your definition, but that can't harm.
The indentation for the description lists is leading space + 2 (in the above commit). Same as the other lists (regardless of the marker). Keep in mind that roman numbering put them off totally (viii => ix), so the marker length is not really an indicator. Exceeding indentation doesn't harm, though.
We always tolerate 1 space off, because of numbering (e.g. 9., => 10.).
It looks like that file has been that way since it was installed in the tree...
That is the problem with regression tests, they only check that nothing has changed :)
Emacs Muse handles this correctly, except that it considers this line to be a blockquote, but it is another problem: it should look at relative indentation to detect blockquotes.
Well, I don't see much point in allowing blockquotes inside lists (beside blowing up the whole thing). Ok that we could reach arbitrary complexity, but in that case a lightweight markup is not the right tool.
I actually wanted to say that Emacs Muse has a bug here, not Text::Amuse. Text::Amuse handles it correctly now. I'm ok with using for nested blockquotes (if someone needs them at all).
The indentation for the description lists is leading space + 2 (in the above commit). Same as the other lists (regardless of the marker). Keep in mind that roman numbering put them off totally (viii => ix), so the marker length is not really an indicator. Exceeding indentation doesn't harm, though.
I am dealing with it in pandoc by requiring indentation to be at least as deep as the last item marker and allowing it to be deeper as long as the whole item contents is deeper. This way it is possible to keep contents of all items aligned even if list goes from 1. to 1000. or has roman numbers. And nested <example>
s work correctly. But neither Emacs Muse nor Text::Amuse handles nested <example>
correctly, so it is just an extension.
Alexander notifications@github.com writes:
And nested
<example>
s work correctly. But neither Emacs Muse nor Text::Amuse handles nested<example>
correctly, so it is just an extension.
Sec. The only reason to have a nested
{{{
}}}
Or:
And this works.
https://github.com/melmothx/text-amuse/blob/master/t/verbatim.t
-- Marco
Sec. The only reason to have a nested
is to write an example with that. And you can do:
I was writing about lists, so nested here means "nested inside a list item", like this:
- <example>
foo
</example>
In
desc-lists.muse
there is a line which says "Back to item", but HTML result is wrong, this line appears to be inside definition list: https://github.com/melmothx/text-amuse/blob/4c2c74d9abf334dc8cd9a6dd9e9d6075fe8e6ab4/t/testfiles/desc-lists.exp.html#L117Emacs Muse handles this correctly, except that it considers this line to be a blockquote, but it is another problem: it should look at relative indentation to detect blockquotes.