Also updated the slash commands to transform the current line to the chosen admonition, comes in handy when you already have the text and want to turn it into an admonition:

playing around with the admonitions this weekend made me discover this weird behavior of texts following the admonition. these are the 3 scenarios behaving differently:
Scenario 1:
-the <div> following the admonition gets a sb-line-blockquote class and the <span> sb-quote class. as if the admonition ābleedsā into the normal text.
Scenario 2:
if I leave an empty line between admonition and next line, everything is fine no extra classes:
Scenario 3:
if i put an empty line as the last line inside the admonition, the line following the admonition doesnāt get those extra classes either:
so my question is, is this intended for some reason, or is it a bug? i didnāt found any reported issue on this on github. can this be corrected easily? as a workaround i can use Scenario 2 and 3, but I wondered can this be repaired in the source code?
@zef ?
[Edit]After w quick chat with ChatGPT, showing it the client/codermirror/admonition.ts and the issue. This was the answer:
The short version: the parser (Lezer) still considers the line following your admonition as part of the same blockquote unless thereās a truly empty line to break the Markdown block.
Hereās the anatomy of your misery:
- The Markdown parserās behaviour
Markdown blockquotes work like this:
> quote line
next line ā still part of blockquote unless thereās a blank line
So unless you explicitly separate with an empty line, the parser wraps both the admonition and the next non-> line inside the same Blockquote node in the syntax tree.
Thatās your Scenario 1.
The
and
with sb-line-blockquote and sb-quote are the renderer saying āStill in blockquote mode, boss.ā
- Your plugin logic assumes the Blockquote node is only the admonition
Your code sees type.name === āBlockquoteā and then slices the entire node text:
const rawText = state.sliceDoc(from, to);
If the parser decided that the next paragraph is part of that same Blockquote node, congratulations: youāre styling it too.
Thereās no check that the block actually ends where your admonition does.
- Why Scenarios 2 and 3 behave
Scenario 2: You leave an empty line.
ā Markdown sees that as the end of the blockquote.
ā Lezer creates a new node for the next paragraph.
ā Your decorations apply cleanly to only the admonition.
Scenario 3: You end your admonition with an empty quoted line (>) or a blank line inside it.
ā That signals the blockquote has formally ended before the next line.
ā Same result as above ā clean separation.
- The fix (pick your poison)
Youāve got options:
A. Detect the end of the admonition yourself
Add logic to stop decorating once the regex match ends, instead of trusting the Blockquote nodeās to.
B. Preprocess your Markdown
Ensure a blank line follows every admonition before parsing ā cheap and effective.
C. Parse stricter
Modify your regex or use ADMONITION_LINE_SPLIT_REGEX to ensure you only capture consecutive > lines as the admonition body.