sslinky/markdoc

Markdown lexer and word document generator.

markdoc's Issues

[BUG] Inline content parsed out of order.

Describe the bug
A more complex test mixing several sections of inline code and plain text fails.

To Reproduce
Steps to reproduce the behavior:

1. Create a markdown test with a single paragraph of alternating plain and inline code.
2. Parse markdown.

Expected behavior
Sections are written to the document in the correct order.

Enhancement: add some simple issue templates to the project

Is your proposal related to a problem?

It would be good to add some issue templates to this repository to facilitate a standardised method of creating bug reports, feature requests, user support etc.

Describe the solution you'd like

The following link shows how to create issue templates:

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

I have some example's here though I'm sure other better ones are available. Would just be nice to have a template to complete to try and ensure submissions are sufficiently detailed.

Describe alternatives you've considered

User stories / bugs could be tracked using other collaborative tools but IMO Github would be the best place for now.

Additional context

N/A

[BUG] Inline code doesn't handle varying numbers of back ticks.

Describe the bug
Start and finish boundaries of inline code must match exactly. At the moment the programme is parsing one back tick as a fence. This is intended so that back ticks can be "escaped" in code if they are different in length to the fence.

e.g.

``A single back tick ` is not the same as the fence``

Parses to:

A single back tick ` is not the same as the fence

Expected behavior
Inline code should only be parsed between back tick delimiters of exactly the same length.

Additional context
https://spec.commonmark.org/0.30/#example-339

[BUG] Inline code regex doesn't identify inline code at start of line.

Describe the bug
Markdown that begins with inline code is not parsed properly.

To Reproduce
Steps to reproduce the behavior:

1. Inline code not inline code.

Expected behavior
Pattern matches on "Inline code" and not on the rest.

[BUG] Inline code not escaping blocks of back ticks.

Two or more back ticks should not be interpreted as inline code markers / fences. They should be parsed literally as either normal text or inline code, depending on where the single back ticks are.

To Reproduce
Steps to reproduce the behavior:

1. Create a markdown file that includes a block of two or more back ticks inside inline code.
   e.g. Some inline code with ```` ticks present.
2. Run the parser.

Expected behavior
Three inline text blocks created with styles normal, inline code, normal, respectively.
Text content is "Some ", "inline code with ```` ticks", and " present." respectively.

Additional context
The root cause is the RegEx pattern that finds inline code.

Enhancement/RFC/Proposal: Add support for Rubberduck folder Navigation

Is your proposal related to a problem?

At the moment importing the whole project is a bit of a chore. One of the pain points I noticed was reconciling whether I had imported all files from all sub directories.

Describe the solution you'd like

To aid in reconciling file imports and to aid in general project navigation, I'd like to add support for Rubberduck folder navidations.

This allows Rubberduck users to more easily check that the structure of the project import matches that of the repository. It also generally improves the project navigation experience when using the Rubberduck project navigator.

Describe alternatives you've considered

Ultimately a refined import process for end users should be considered. The proposed solution would act as a temporary measure mainly for the benefit of project maintainers.

Additional context

N/A