Summary
When editing an empty unordered list item such as - , pressing Enter briefly removes the list marker as expected, but the marker is then inserted again and the line returns to an empty list item.
This appears to contradict the engine's intended behavior in MarkdownListHandler.removeLinePrefixAndExit, where an empty list item should remove the current line prefix and leave the caret on a plain empty line.
Steps to reproduce
- Embed
NativeTextViewWrapper with the default list helpers enabled.
- Type
- item.
- Press Enter to create the next list item. The buffer becomes something like:
- With the caret on the empty
- item, press Enter again.
Expected behavior
The empty list item exits list mode:
The caret should remain on the plain empty line, with no - / bullet marker restored.
Actual behavior
The list prefix is removed briefly, then - is inserted again and the editor returns to an empty unordered list item. Visually this shows as the bullet coming back.
Notes / suspected cause
The current source looks like it intentionally handles this case in MarkdownListHandler.handleInsertion:
contentText.isEmpty for a list line calls removeLinePrefixAndExit(...).
removeLinePrefixAndExit(...) removes the prefix and sets the caret at the line start.
The observed behavior looks similar to an NSTextView / Text Services Manager double-insertion issue: the command path handles the Enter and removes the prefix, then a later text insertion path restores the newline/list continuation text.
In our downstream app we previously had to guard this class of issue by blocking the next TSM insert after programmatically removing the empty list prefix. I do not see an equivalent guard in the current engine; performEdit sets isProgrammaticEdit, but that only bypasses delegate handling during the programmatic edit itself.
Environment
- macOS app using
NativeTextViewWrapper
- TextKit 2-backed editor
lists.helpersEnabled == true- Reproduced from a local checkout of
nodes-app/swift-markdown-engine used as a local Swift package
Summary
When editing an empty unordered list item such as
-, pressing Enter briefly removes the list marker as expected, but the marker is then inserted again and the line returns to an empty list item.This appears to contradict the engine's intended behavior in
MarkdownListHandler.removeLinePrefixAndExit, where an empty list item should remove the current line prefix and leave the caret on a plain empty line.Steps to reproduce
NativeTextViewWrapperwith the default list helpers enabled.- item.-item, press Enter again.Expected behavior
The empty list item exits list mode:
- itemThe caret should remain on the plain empty line, with no
-/ bullet marker restored.Actual behavior
The list prefix is removed briefly, then
-is inserted again and the editor returns to an empty unordered list item. Visually this shows as the bullet coming back.Notes / suspected cause
The current source looks like it intentionally handles this case in
MarkdownListHandler.handleInsertion:contentText.isEmptyfor a list line callsremoveLinePrefixAndExit(...).removeLinePrefixAndExit(...)removes the prefix and sets the caret at the line start.The observed behavior looks similar to an
NSTextView/ Text Services Manager double-insertion issue: the command path handles the Enter and removes the prefix, then a later text insertion path restores the newline/list continuation text.In our downstream app we previously had to guard this class of issue by blocking the next TSM insert after programmatically removing the empty list prefix. I do not see an equivalent guard in the current engine;
performEditsetsisProgrammaticEdit, but that only bypasses delegate handling during the programmatic edit itself.Environment
NativeTextViewWrapperlists.helpersEnabled == truenodes-app/swift-markdown-engineused as a local Swift package