hugo
hugo copied to clipboard
Support for cooklang
I would love to see support for cooklang, which is a lesser known language for cooking recipes, but very promising. Since a lot of hugo websites are about cooking or recipes in general, I think a lot of content would benefit of an implementation directly in hugo.
There is also a detailed specification: https://cooklang.org/docs/spec/
Possible implementations:
- A specific file extension rendering a specific kind of template (e.g.
stove-pot-roast-with-mashed-potatoes.cooklang) - A code block containing the language spec
```cooklang - A kind of partial or template function, that can render this kind of content
Hacker News discussion: https://news.ycombinator.com/item?id=28997309
What do you think?
This is interesting, but a distraction. Instead of implementing another parser, use the CLI:
cook recipe read recipe.cook --output-format yaml > recipe.yaml
With a page bundle:
content/recipes/
└── easy-pancakes/
├── featured.webp
├── index.md
├── recipe.cook
└── recipe.yaml
The well-formatted YAML data is available as a page resource:
{{ with .Resources.GetMatch "recipe.yaml" }}
{{ $d := transform.Unmarshal . }}
...
{{ end }}
There is a parser written in Go out there, but I don't see us adding support for this anytime soon. It's a little to ... niche? I would probably not say that if I worked as a pastry chef, though.
The code block feature could probably be asked for in the Chroma project directly?
https://github.com/alecthomas/chroma
@jmooring
This is interesting, but a distraction.
Sorry for that.
Instead of implementing another parser, use the CLI:
Thank you for that ;-)
@bep, @davidsneighbour
There is a parser written in Go out there, but I don't see us adding support for this anytime soon. It's a little to ... niche? I would probably not say that if I worked as a pastry chef, though.
The code block feature could probably be asked for in the Chroma project directly?
You may all be right. While it is an interesting language, it might be not the right place to ask for support in here. Did not want to distract you from more interesting / important stuff.
Should I leave the issue open, maybe someone else would like to help with a PR?
Should I leave the issue open, maybe someone else would like to help with a PR?
You can leave this issue open, but we need some kind of consensus before a PR is written. The work of creating such a PR is only a small fraction of the cost of maintaining such a feature for the next 5 years, so we need to carefully consider the cost/value first.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.