Inconvenient Content StringSlice for emphasis delimiter literal inlines #623

New Issue

claunia · 2026-01-29T14:41:24Z

claunia commented

2026-01-29 14:41:24 +00:00

Originally created by @zickb on GitHub (Aug 30, 2023).

When an open emphasis delimiter is found but no closing emphasis delimiter, then the delimiter will be converted to an LiteralInline.
This LiteralInline have a content Property which contains only the delimiter string literal as text.
A regular LiteralInline has a content Property containing the whole text and an appropriate start and end index instead.

E.g.:
Test input: test*test
=> Paragraph
|-----------Container Inline
|----------------Literal Inline (Content: test*test, Start: 0, End: 3)
|----------------Literal Inline (Content: , Start: 0, End: 0)
|----------------Literal Inline (Content: testtest, Start: 5, End: 8)

This structure is in my opinion very inconvenient and make thinks like text search above multiple literal inlines unnecessary "hard".
(But thats just my opinion and maybe I'm wrong. In that case please feel free to discard the pull request #736 and this issue.)

Originally created by @zickb on GitHub (Aug 30, 2023). When an open emphasis delimiter is found but no closing emphasis delimiter, then the delimiter will be converted to an `LiteralInline`. This `LiteralInline` have a content Property which contains only the delimiter string literal as text. A regular `LiteralInline` has a content Property containing the whole text and an appropriate start and end index instead. E.g.: Test input: `test*test` => Paragraph |-----------Container Inline |----------------Literal Inline (Content: test*test, Start: 0, End: 3) |----------------Literal Inline (Content: *, Start: 0, End: 0) |----------------Literal Inline (Content: test*test, Start: 5, End: 8) This structure is in my opinion very inconvenient and make thinks like text search above multiple literal inlines unnecessary "hard". (But thats just my opinion and maybe I'm wrong. In that case please feel free to discard the pull request #736 and this issue.)

claunia added the enhancement label 2026-01-29 14:41:24 +00:00

claunia closed this issue

2026-01-29 14:41:24 +00:00

claunia commented

2026-01-29 14:41:25 +00:00

@MihaZupan commented on GitHub (Aug 30, 2023):

The offset of a StringSlice should be an implementation detail. We may or may not point to the original source text as a performance optimization to avoid allocating substrings.

If you care about locations in the original text, you should enable UsePreciseSourceLocation and then look at the Span/Line/Column properties of the MarkdownObjects in the syntax tree.

private static readonly MarkdownPipeline s_preciseSourceLocations = new MarkdownPipelineBuilder()
    .UsePreciseSourceLocation()
    .Build();

@MihaZupan commented on GitHub (Aug 30, 2023): The offset of a `StringSlice` should be an implementation detail. We may or may not point to the original source text as a performance optimization to avoid allocating substrings. If you care about locations in the original text, you should enable `UsePreciseSourceLocation` and then look at the `Span`/`Line`/`Column` properties of the `MarkdownObject`s in the syntax tree. ```c# private static readonly MarkdownPipeline s_preciseSourceLocations = new MarkdownPipelineBuilder() .UsePreciseSourceLocation() .Build(); ```

claunia commented

2026-01-29 14:41:26 +00:00

@xoofx commented on GitHub (Aug 30, 2023):

I agree with the problem of the delimiter and the fix from PR #736 is merged, thanks!

Otherwise regarding:

make thinks like text search above multiple literal inlines unnecessary "hard"

I agree with @MihaZupan here:

If you care about locations in the original text, you should enable UsePreciseSourceLocation

For the reason that we don't guarantee always keeping a link to the original string for StringSlice. Afair, there are cases where we generate a new string because we make the expansion of it, so a StringSlice would not always point to the original string (but in the delimiter case above, it was indeed better to keep a reference to the original StringSlice than to recreate a string)

@xoofx commented on GitHub (Aug 30, 2023): I agree with the problem of the delimiter and the fix from PR #736 is merged, thanks! Otherwise regarding: > make thinks like text search above multiple literal inlines unnecessary "hard" I agree with @MihaZupan here: > If you care about locations in the original text, you should enable UsePreciseSourceLocation For the reason that we don't guarantee always keeping a link to the original string for StringSlice. Afair, there are cases where we generate a new string because we make the expansion of it, so a `StringSlice` would not always point to the original string (but in the delimiter case above, it was indeed better to keep a reference to the original StringSlice than to recreate a string)

claunia referenced this issue

2026-01-29 14:50:27 +00:00

[PR #623] [MERGED] Fix GlobalizationExtension RTL detection #1148

claunia referenced this issue

2026-01-29 14:50:30 +00:00

[PR #623] Fix GlobalizationExtension RTL detection #1153

Sign in to join this conversation.