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

$MDX delimiters in ocaml cut off any code on the same line #374

Closed
ceastlund opened this issue Apr 21, 2022 · 3 comments · Fixed by #387
Closed

$MDX delimiters in ocaml cut off any code on the same line #374

ceastlund opened this issue Apr 21, 2022 · 3 comments · Fixed by #387

Comments

@ceastlund
Copy link

If I write code like this:

(* $MDX part-begin=something *)
type t =
  | Foo
  | Bar (* $MDX part-end *)

Then what shows up in the MDX is:

type t =
  | Foo

This cuts off | Bar. Granted, a solution is to always put the comment on a separate line. But ocamlformat doesn't know this, for example. It would be better if mdx always preserved all the code between delimiters.

@NathanReb
Copy link
Contributor

Out of curiosity, does ocamlformat still format it this way if you had an empty line between | Bar and the comment?

I understand this is annoying but I'm wondering if from a user perspective, you really want inline part delimiters. If there's no way to get ocamlformat and MDX to agree on how this, we'll of course fix it in MDX but I'm wondering whether this is the formatting you actually want or if you'd also rather have it on a separate line.

@Leonidas-from-XIV
Copy link
Collaborator

@ceastlund Thanks for the report and the example. I'm currently trying to implement a reasonable solution to this problem. Could you specify a configuration where OCamlformat formats the comment on the end of the line? I'm playing around with source code like this:

(* $MDX part-begin=something *)
type t =
  | Foo
  | Bar
  | Baz
  | Quuz
  | Fnuug
  | Gbaz of { foo : int; bar : int; baz : int; bat : int }
  | Hoog
(* $MDX part-end *)

to get ocamlformat 0.21 to put the part-end on the same line as Hoog but with both the conventional and janestreet profiles it leaves it on its own line (the conventional profile puts types with less variants on one line but the part-end stays on a separate line. Unfortunately, there's a ton of flags so it would be good to have a reproducible case that we can reach out to the OCamlformat maintainers to find a solution that is both readable and doesn't drop lines silently.

@ceastlund
Copy link
Author

I believe the case I've run into is when there's an [@@deriving] clause on a new line after the comment, and the comment is aligned with the "|" on the previous line, it gets moved up to after "Hoog". And if it's after "Hoog", it stays there.

Leonidas-from-XIV added a commit to Leonidas-from-XIV/opam-repository that referenced this issue Jan 6, 2023
CHANGES:

#### Added

- Report all parsing errors in Markdown files (realworldocaml/mdx#389, @NathanReb)

#### Changed

- Preserve indentation in multiline OCaml blocks in .mli files (realworldocaml/mdx#395, @panglesd)

#### Fixed

- Fixed compatibility with Cmdliner 1.1.0 (realworldocaml/mdx#371, @Leonidas-from-XIV)
- Report errors and exit codes of toplevel directives (realworldocaml/mdx#382, @talex5,
  @Leonidas-from-XIV)
- Fix block locations in error reporting (realworldocaml/mdx#389, @NathanReb)
- Include the content of the line that features the `part-end` MDX directive in
  the output, before that line would've been dropped (realworldocaml/mdx#374, realworldocaml/mdx#387,
  @Leonidas-from-XIV)
- Handle EINTR signal on waitpid call by restarting the syscall. (realworldocaml/mdx#409, @tmcgilchrist)
- Fix parsing of multiline toplevel phrases in .mli files (realworldocaml/mdx#394, realworldocaml/mdx#397,
  @Leonidas-from-XIV)

#### Removed

- Removed warning about missing semicolons added in MDX 1.11.0 and the
  automatic insertion of semicolons in the corrected files introduced in MDX
  2.0.0. (realworldocaml/mdx#398, @Leonidas-from-XIV)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants