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 "lhs" as name for literate Haskell #4510

Closed
ad-si opened this issue Mar 29, 2018 · 5 comments
Closed

Support "lhs" as name for literate Haskell #4510

ad-si opened this issue Mar 29, 2018 · 5 comments
Labels

Comments

@ad-si
Copy link
Contributor

@ad-si ad-si commented Mar 29, 2018

When converting markdown to markdown+lhs following 2 variants should yield the same output:

``` {.literate .haskell}
main = putStr "Hello World!"
```
```lhs
main = putStr "Hello World!"
```

should both yield

> main = putStr "Hello World!"
@jgm
Copy link
Owner

@jgm jgm commented Apr 2, 2018

The behavior is exactly as documented in the manual, isn't it?

In Markdown [+lhs] output, code blocks with classes haskell and literate will be rendered using bird tracks, and block quotations will be indented one space, so they will not be treated as Haskell code.

Nothing is said here about lhs. Your code block with lhs is just a regular code block.

@jgm
Copy link
Owner

@jgm jgm commented Apr 2, 2018

I think it's actually quite useful to have a way to do both of these things in a Markdown document:

  1. Insert some literate Haskell, which will be treated as code in markdown+lhs output.
  2. Insert a regular code block which happens to display some literate Haskell code, and which will be highlighted as such in output formats that do highlighting.
@jgm jgm added the out of scope? label Apr 2, 2018
@ad-si
Copy link
Contributor Author

@ad-si ad-si commented Apr 2, 2018

I think it's actually quite useful to have a way to do both of these things in a Markdown document:

Yeah, I guess you're right!

It just bugs me, that it's not really correct markdown, or rather markdown which other parsers can easily handle. E.g. Commonmark will do this:

```{.literate .haskell}
etst
```

<pre lang="{.literate"><code>etst
</code></pre>

Which is not really what anyone wants, who writes this code...

Other parsers completely mess it up: gettalong/kramdown#503

It would be cool if there was a more standard compliant way to differentiate between Haskell code which gets displayed and code which gets executed ...

@jgm
Copy link
Owner

@jgm jgm commented Apr 2, 2018

@ad-si
Copy link
Contributor Author

@ad-si ad-si commented Apr 2, 2018

Well, for the time being I use this workaround to execute / compile the Haskell:

cat document.md \
| sed 's/```haskell/```{.literate .haskell}/g' \
| pandoc \
  --from markdown \
  --to markdown+lhs \
  --output temp.lhs \
| stack runhaskell \
  --resolver lts-11.1 \
  --package cmdargs \
  -- \
  temp.lhs \
; rm -f temp.lhs

Not glamorous, but get's the job done =P.
I'll switch to a Haskell pipeline for my blog in the future (shake + pandoc probably), then the lua filter might be a good idea. Thanks for the tip.

@jgm jgm closed this Dec 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants