Replacing before source position (inline parser) #111

Closed
opened 2026-01-29 14:27:17 +00:00 by claunia · 4 comments
Owner

Originally created by @clarkd on GitHub (May 12, 2017).

I'm currently writing a simple extension for Markdig that searches for references to an issue in our issue tracking software (JIRA) and automatically converts them to a hyperlink. They are of the format: XX-1234 where XX is the project key.

I've written an inline parser with the OpeningCharacters set to '-', and then I peek previous characters to read the project key.

The issue comes to when I want to add the new inline element in it's place. From what I can tell I can't provide a value less than the slice's start position to processor.Inline.Span.Start - it just seems to ignore it and I end up with something like the following - with the latter part linked.

SUSU-1234

Any ideas?

Originally created by @clarkd on GitHub (May 12, 2017). I'm currently writing a simple extension for Markdig that searches for references to an issue in our issue tracking software (JIRA) and automatically converts them to a hyperlink. They are of the format: XX-1234 where XX is the project key. I've written an inline parser with the OpeningCharacters set to '-', and then I peek previous characters to read the project key. The issue comes to when I want to add the new inline element in it's place. From what I can tell I can't provide a value less than the slice's start position to processor.Inline.Span.Start - it just seems to ignore it and I end up with something like the following - with the latter part linked. SUSU-1234 Any ideas?
claunia added the questionenhancement labels 2026-01-29 14:27:17 +00:00
Author
Owner

@xoofx commented on GitHub (May 12, 2017):

Yes, it is a normal behavior, as the previous parser has matched until the beginning of your opening character.

I would suggest to simply remove OpeningCharacters (leave it null array or empty), and match the full pattern from there (so XX-1234). When you don't specify OpeningCharacters, the parser is considered a global parser, and is always executed after the other parsers (that have OpeningCharacters)

Alternatively, your parser could take a list of prefix JIRA issue and fill the appropriate OpeningCharacters.

If you can OSS this extension, I would be glad to integrate it as part of Markdig as linking to a JIRA issue is a pretty common enterprise scenario, so PR welcome!

@xoofx commented on GitHub (May 12, 2017): Yes, it is a normal behavior, as the previous parser has matched until the beginning of your opening character. I would suggest to simply remove OpeningCharacters (leave it null array or empty), and match the full pattern from there (so XX-1234). When you don't specify OpeningCharacters, the parser is considered a global parser, and is always executed after the other parsers (that have OpeningCharacters) Alternatively, your parser could take a list of prefix JIRA issue and fill the appropriate OpeningCharacters. If you can OSS this extension, I would be glad to integrate it as part of Markdig as linking to a JIRA issue is a pretty common enterprise scenario, so PR welcome!
Author
Owner

@clarkd commented on GitHub (May 12, 2017):

OK - that's good to know. It's been a little tricky figuring out what's what just from the existing extensions but seem to have got there.

Because the pattern changes, e.g. the 'XX' is the project key defined by the user. In our JIRA we have projects such as 'COMM', 'SU', 'TEST' etc. In the end I set the opening characters to be the uppercase alphabet (A-Z) and that seems to have worked a treat. I can now read as many uppercase characters, expect a dash and then read the issue number.

I did wonder about taking a list of JIRA project keys as a setting but the above automatic method seems so much nicer!

I've just pushed the extension to one of my repos (https://github.com/clarkd/MarkdigJiraLinker) - feel free to take a look and let me know your thoughts. It would be great to get this integrated into Markdig directly!

@clarkd commented on GitHub (May 12, 2017): OK - that's good to know. It's been a little tricky figuring out what's what just from the existing extensions but seem to have got there. Because the pattern changes, e.g. the 'XX' is the project key defined by the user. In our JIRA we have projects such as 'COMM', 'SU', 'TEST' etc. In the end I set the opening characters to be the uppercase alphabet (A-Z) and that seems to have worked a treat. I can now read as many uppercase characters, expect a dash and then read the issue number. I did wonder about taking a list of JIRA project keys as a setting but the above automatic method seems so much nicer! I've just pushed the extension to one of my repos (https://github.com/clarkd/MarkdigJiraLinker) - feel free to take a look and let me know your thoughts. It would be great to get this integrated into Markdig directly!
Author
Owner

@xoofx commented on GitHub (May 12, 2017):

The extension looks good to me, so feel free to make a PR!

@xoofx commented on GitHub (May 12, 2017): The extension looks good to me, so feel free to make a PR!
Author
Owner

@xoofx commented on GitHub (May 18, 2017):

Closing this issue as it was solved differently as part of PR #113

@xoofx commented on GitHub (May 18, 2017): Closing this issue as it was solved differently as part of PR #113
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/markdig#111