Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified markdown-regex-header to require a space between # and heading text #35

Closed
wants to merge 1 commit into from

Conversation

plantarum
Copy link
Contributor

When a markdown document contains a code block for a language that uses # as a comment character, folding is broken. For example, in the following markdown text:

# Heading One

` ``r
#Comment on code
myFunction <- function
` ``

## Subheading A

Folding the first header produces the following:

# Heading One
#Comment on code
myFunction <- function
` ``

## Subheading A

In effect, my code comment is treated as a heading for the folding algorithm.

A simple fix is updating the heading regexp to require a space (\s-+), rather than allow a space (\s-*), after the opening # symbols. This appears to be consistent with the markdown specification, in which all headlines are of the form "# Heading 1" rather than "#Heading 1".

As a consequence, in code blocks we cannot use a space between the # and the code. The alternative would require detecting and ignoring lines that occur in a code block, which would be more involved.

Thanks for your time,

Tyler

The new regexp will not match lines with no space between the # and
subsequent text: '#not a heading', '# A real heading'. This improves
folding behaviour when the document includes code blocks with comment
lines.
@vyp
Copy link

vyp commented Oct 29, 2015

As a consequence, in code blocks we cannot use a space between the # and the code.

So we cannot have a comment character #, then a space, and then the comment? i.e. # Comment on code? I don't think that would be a good solution.

Also, maybe off topic, but why do you have a space in your three backticks? Is that valid, or is that a typo?

@plantarum
Copy link
Contributor Author

I agree this is not ideal. But to be clear, right now, with no changes, comments with or without a space in source code blocks are treated as markdown headings. My change would mean that comments without a space would be ignored. I'm not introducing a new problem, I'm partially fixing an existing problem.

It would be much better to solve the problem entirely, but as I mentioned above, that requires more work in the outline-mode code responsible for section folding. I'm not familiar enough with that to know how easy or hard it would be.

I put a space in my backticks so they would get displayed as backticks, and not interpreted as the end of the code block. It's not correct syntax, but close enough to convey the issue I think. I tried escaping the backticks with a backslash, but that didn't work.

@vyp
Copy link

vyp commented Oct 30, 2015

I'm not introducing a new problem, I'm partially fixing an existing problem.

Yes I see now this is correct, thanks for clarifying. (I guess once/if #33 is fixed, this change can be reverted.)

I put a space in my backticks so they would get displayed as backticks, and not interpreted as the end of the code block.

Ah I see. You could always indent your block by four spaces to do this (instead of using backticks):

# Heading One

```r
#Comment on code
myFunction <- function
```

## Subheading A

This will not do syntax highlighting though. But at least you can convey the text correctly.

@plantarum
Copy link
Contributor Author

Yes, I hadn't seen issue 33, but that is exactly the problem my PR addresses, in a clumsy and incomplete way.

@jrblevin
Copy link
Owner

jrblevin commented Nov 2, 2015

Indeed, this is related to #33. The folding and imenu code needs to be rewritten to ignore false positives (lines appearing to be ATX headers) inside fenced code blocks.

I agree that having a space between the hash mark and heading text is stylistically preferred. However, I allowed the space to be optional so that markdown-mode would be as permissive as possible and maintain compatibility with Markdown.pl and the vast majority of Markdown processors that do allow headings without spaces.

@jrblevin jrblevin closed this Nov 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants