Code Monkey home page Code Monkey logo

punct's Introduction

Punct

Punct is a programming environment for publishing things, implemented in Racket. It uses inline Racket code to extend CommonMark-flavored Markdown, which is parsed into a format-independent AST that can be rendered in HTML (or any other target file type).

Documentation is at https://joeldueck.com/what-about/punct/.

Installation

Clone this repository, and from within the checkout’s root folder, do raco pkg install --link punct-lib/ punct-doc/ (note the trailing slashes).

Once this is done, try it out by following along with the Quick Start.

punct's People

Contributors

bogdanp avatar otherjoel avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

punct's Issues

Rendering shouldn’t be sensitive to attribute order

The match patterns in render/base.rkt (and elsewhere) match reliably against elements created by the Commonmark parser because the set and order of attributes is consistent. But an author may generate txexprs of their own and these will amost never match.

#lang punct

`doc->html` will convert this to an `img` tag: ![Image 1](image1.jpg)

But not this: •'(image [[src "image3.jpg"]])

Reconsider: should document body be `(listof xexpr?)`

When writing Punct, there was a question of what guarantees I should make about the body element of document. I started by making it a very straight translation of the commonmark package’s document structure1 into a list. Hence, Punct’s documentation specifies document-body as simply list?.

After some feedback, I’m revisiting this question. It would be more ergonomic to make this value (listof xexpr?). This way, people could make use of the familiar xml and txexpr packages to manipulate the document’s elements. Further, I could uniformly require that custom elements also be xexpr?, and the same requirements and guarantees would hold at all phases of parsing the document. I don’t think there would be any downside.

Footnotes

  1. That package uses structs for every element, and so does things like using actual integers for heading levels because it has no reason to do otherwise. '(heading [[level 2]] "Abstract") is not a valid x-expression, however (attributes must be strings), so it cannot be manipulated by the functions from xml or txexpr.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.