-
-
Notifications
You must be signed in to change notification settings - Fork 329
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
Codespan containing single space. #569
Comments
I'm moving this to the spec repository, since the spec is vague here. I'm fairly convinced that we should make a change here. Whatever changes are made will of course have to be made in implementations. The idea I like best is to add the phrase
In cmark we're already traversing the whole string looking for newlines, so we can easily keep track of whether a nonspace character has been seen. This allows code spans with any number of spaces, which I think we want. Drawbacks to making a change: You can no longer express "empty code span" in markdown. I don't like this kind of expressive limitation. And note that you can create a code span with one space (with current behavior) by putting three spaces between backticks. |
|
You cannot express “empty emphasis span” or empty link in Commonmark either: |
Then maybe it could be redefined so that a code span has
Then one space would render as one space; and two spaces would render as empty code span. Currently empty code span can be rendered both by single space or two spaces which is too generous... |
Thinking about both of these comments, I'm coming
around to not worrying much about making empty code
spans inexpressible. Much more important to make it
easy and natural for writers to express "code span
with one space" and "code span with two spaces."
|
I noticed the recent changes to the specs regarding code spans and the new rules for eating just one initial and trailing spaces.
Currently, for single space between backticks, cmark renders an empty code span:
But it would imho be better to render a code span with single space instead.
Rationale:
Either way, the specs should imho contain an example documenting how to render the given input.
The text was updated successfully, but these errors were encountered: