Skip to content

Change and unify markup for (poly)variants and records #82

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

Closed
dbuenzli opened this issue May 30, 2017 · 3 comments
Closed

Change and unify markup for (poly)variants and records #82

dbuenzli opened this issue May 30, 2017 · 3 comments
Assignees

Comments

@dbuenzli
Copy link
Contributor

Tables with fixed width columns don't scale and can lead to unreadable definitions (example).

We agreed with @trefis that it was better to render them as we do for module member: each member/case being in its own div with a properly labelled internal div for the definition (which can be made to wrap like function definitions do) and another div for the doc string.

@dbuenzli dbuenzli changed the title Change and unify markup for polyvar and records Change and unify markup for (poly)variants and records May 30, 2017
@rizo rizo self-assigned this Oct 8, 2018
@github-actions
Copy link

github-actions bot commented May 1, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@github-actions github-actions bot added the stale label May 1, 2020
@dbuenzli dbuenzli removed the stale label May 1, 2020
@github-actions
Copy link

github-actions bot commented Jun 1, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. The main purpose of this is to keep the issue tracker focused to what is actively being worked on, so that the amount and variety of open yet inactive issues does not overwhelm contributors.

An issue closed as stale is not rejected — further discussion is welcome in its closed state, and it can be resurrected at any time. odoc maintainers regularly check issues that were closed as stale in the past, to see if the time is right to reopen and work on them again. PRs addressing issues closed as stale are as welcome as PRs for open issues. They will be given the same review attention, and any other help.

@github-actions github-actions bot added the stale label Jun 1, 2020
@dbuenzli dbuenzli added not stale and removed stale labels Jun 1, 2020
@dbuenzli
Copy link
Contributor Author

See #614 for a proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants