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

🤺 Amenable Fences #482

Merged
merged 10 commits into from
May 30, 2023
Merged

🤺 Amenable Fences #482

merged 10 commits into from
May 30, 2023

Conversation

zampino
Copy link
Collaborator

@zampino zampino commented May 11, 2023

The purpose of these changes is two-fold:

  • Help solving annoying issues with the undesired evaluation of code in markdown fenced code blocks (currently always treated as clojure code meant for evaluation) like this repo's README.md. Also introduces a skip or eval=false (inspired by RMarkdown/KnitR) annotaions to be used to signal a clojure fenced block should not be evaluated:
```clojure {:nextjournal.clerk/code-listing true}
'(1 2 "not evaluated" :but-still-highlighted)
```
  • Prepare for highlighting inert markdown fenced code with suitable prosemirror styles. Don't highlight languages other than clojure for the moment.

@zampino zampino marked this pull request as ready for review May 23, 2023 10:25
@zampino zampino changed the title 🤺 Fences 🤺 Amenable Fences May 23, 2023
@mk
Copy link
Member

mk commented May 24, 2023

I don't really like skip as I think it's ambiguous. eval=false is much clearer but then I also don't love that the default is true.

Looking at prior art, quarto seems to use eval=false under the execute key in all its markdown flavors:

Ignoring this prior art (which I'm not sure we should do) I think I'd prefer something like no-eval=true or code-listing=true. In general I think it's good that we give some thought to how we want to support other clerk attributes to enable foldable code-listings or controlling width for example in languages that aren't clojure.

@mk
Copy link
Member

mk commented May 24, 2023

Leaning towards edn in the annotations so:

```javascript {:nextjournal.clerk/visibility {:code :fold} :nextjournal.clerk/code-listing true}
41 + 1
```

Potentially dropping the namespace step and namespacing programmatically:

```javascript {:visibility {:code :fold} :code-listing true}
41 + 1
```

Which we then namespace so {:nextjournal.clerk/visibility {:code :fold} :nextjournal.clerk/code-listing true}.

If we want to support a short-hand like for Clojure metadata we could read multiple times and merge, i.e.

```javascript :code-listing {:visibility {:code :fold}}
41 + 1
```

For now I think I'm leaning towards the first option. A bit longer, but nice, simple & explicit.

@mk mk merged commit 6bbda19 into main May 30, 2023
@mk mk deleted the fences branch May 30, 2023 09:29
craig-latacora pushed a commit to latacora/clerk that referenced this pull request Aug 7, 2023
By specifying `{:nextjournal.clerk/code-listing true}` after the language.
---------

Co-authored-by: Martin Kavalar <martin@nextjournal.com>
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.

2 participants