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

Support scopes for code fence attributes #145

Open
michaeltlombardi opened this issue Aug 25, 2023 · 1 comment
Open

Support scopes for code fence attributes #145

michaeltlombardi opened this issue Aug 25, 2023 · 1 comment

Comments

@michaeltlombardi
Copy link

Currently, the grammar parses the attributes after the language ID for a code fence as a single token with the scope fenced_code.block.language.attributes.markdown:

```sh {higlight="content:~/$foo"}
cd ~/$foo
```

Example parsing, showing the textmate scopes includes fenced_code.block.language.attributes.markdown

It would be more readable/useful to be able to parse this a little further:

  • { is the punctuation that begins the attributes
  • highlight is an attribute name
  • = is an assignment operator
  • "content:~/$foo" is an attribute value and a string
  • } is the punctuation that ends the attributes

There's some commonly used syntax where .foo indicates a CSS class and #bar indicates an HTML ID, but otherwise I think the primary scopes are:

  • { and } for beginning and ending punctuation
  • attribute names may be either standalone, like { disabled } or name-value pair, like { attrName="attrValue" }
  • = is the assignment operator for an attribute name-value pair
  • Values must be boolean true/false, numeric, or a quoted string1

I don't know enough about scope naming definitions to have good suggestions for the scopes to define, I just know enough to have noticed this limitation for the grammar.

Footnotes

  1. There are a few Markdown parsers that support complex data types here, like arrays in [] or objects in {}, but I think that's probably too complex to get into, at least on a first pass.

@reenberg
Copy link

It is worth noting that MkDocs doesn't support that syntax. It is fairly lenient with the requirements of curly braces and period on the language class, but when the language definition is combined with other classes, then its quite strict:

the curly braces and dot are required for all classes, including the language class if more than one class is defined

An example, compliant with MkDocs would be

``` bash
# Some comment
echo "Hello World"
```

``` .bash
# Some comment
echo "Hello World"
```

``` { .bash } 
# Some comment
echo "Hello World"
```

``` { .bash .class #id title="Title of the code block" } 
# Some comment
echo "Hello World"
```

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

No branches or pull requests

2 participants