feat: multi-lines

[ldez]

Basic multi-lines for unambiguous elements.

[ldez]

@nicorikken @mojavelinux Is that kind of behavior acceptable to you?

foobar

footnoteref:[id, text text
text text text]

foobar

footnoteref:[id, text text
text text
text

foobar

[nicorikken]

Somewhat better, assuming people don't make mistakes like leaving out the closing brackets. But that would better be handled using a linter. this highlighting assumes a valid Asciidoctor syntax, which I think is fine. It breaks gracefully though 😸 Some of my edge case testing:

foobar

footnoteref:[id, text text
text text text]

foobar

footnoteref:[id, text text
text text
text

foobar

I think this is still better than the single-line variant.

[ldez]

If you assuming this is possible, I apply this to:

• footnote(ref)
• passthrough (only the pass:[text] variant)
• stem
• xref (only the xref:id[reftext] variant)

[nicorikken]

Certainly I think you can add this to the other constructs with a similar (bounded) syntax. That leave only the more conflicting constructs up for debate.

[ldez]

I can do that:

Is this expected behavior?

[ldez]

It's ready to review.

Say me if spaces at the ending of line are invalid characters.

[ldez]

I have also fixed all macros for respect naming conventions and styling.

[nicorikken]

I see no breakage in practical coloring (due to renaming). Code is nice. Spaces at the end seem to render neatly in Asciidoc preview plugin, so would be valid. As long as the macro is closed.

This can be merged.

[mojavelinux]

Say me if spaces at the ending of line are invalid characters.

The first thing the converter does is strip all trailing whitespace. So technically it is valid because it is ignored. But we could highlight it as an error to show that it will get stripped away and is thus superfluous.

[mojavelinux]

Somewhat better, assuming people don't make mistakes like leaving out the closing brackets. But that would better be handled using a linter.

True. It's also unavoidable given the current behavior of first-mate. They really, really, really need to add a way to validate the inner content against a spec. Right now, this is the very best we can do.