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

Should nested comment+code_block be accepted ? #375

Closed
hhugo opened this issue Aug 17, 2019 · 5 comments
Closed

Should nested comment+code_block be accepted ? #375

hhugo opened this issue Aug 17, 2019 · 5 comments

Comments

@hhugo
Copy link

hhugo commented Aug 17, 2019

(**
  This is a comment with code inside
  {[
    (** This is a comment with code inside
        {[ let code inside = f inside ]}
    *)
    let code inside = f inside
  ]}
*)
@aantron
Copy link
Contributor

aantron commented Aug 17, 2019

To clarify, the problem is the nested ]} that is inside the nested (** ... *).

What is the natural scenario in which this kind of input arises?

@hhugo
Copy link
Author

hhugo commented Aug 17, 2019

This came up while writing tests for ocamlformat.
I don't know if there is a natural scenario for this.
If we don't plan to support it, it would be good to document the restriction.

aantron added a commit that referenced this issue Aug 17, 2019
@aantron
Copy link
Contributor

aantron commented Aug 17, 2019

I'm inclined not to support it, unless we find someone is really using this.

@dbuenzli
Copy link
Contributor

dbuenzli commented Sep 1, 2019

I think we should try, not doing so would prevent the ability of extracting (see #303) any OCaml source file.

@github-actions
Copy link

github-actions bot commented May 2, 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, i.e. they will be given the same review attention, and any other help.

@github-actions github-actions bot added the stale label May 2, 2020
@github-actions github-actions bot closed this as completed May 9, 2020
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