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

how to apply ocamlformat #55

Open
cdaringe opened this issue May 2, 2021 · 5 comments
Open

how to apply ocamlformat #55

cdaringe opened this issue May 2, 2021 · 5 comments

Comments

@cdaringe
Copy link

cdaringe commented May 2, 2021

problem

dune build @fmt --watch yields

ocamlformat: ignoring "src/bin/server/bin.eml.ml" (syntax error)

when using eml

discussion

do you use ocamlformat? if so, how? perhaps https://dune.readthedocs.io/en/stable/dune-files.html#dialect is relevant?

@aantron
Copy link
Owner

aantron commented May 2, 2021

Ah, this is indeed an oversight. I don't use OCamlFormat, as you can probably tell :)

The original intent was that as projects get more elaborate, the templates will get factored out into their own files, that are mostly HTML with only a bit of OCaml code. Those files shouldn't require formatting (at least by an OCaml formatter). They would be named like foo.eml.html to trigger HTML highlighting due to their mostly HTML content. I think that would bypass the OCamlFormat error.

Another option is to try refmt. Perhaps eml is similar enough to JSX. It might be awkward to set up and use for .eml.ml files, though.

Thanks for the link to (dialect ...). It looks almost useful for this, but:

  • The rule that dots aren't allowed in extensions means that .eml.ml files can't be distinguished from .ml.
  • The preprocessor is required to output a binary AST, while eml currently outputs OCaml text.

It's likely possible to at least disable OCamlFormat on template files by either patching Dune, or by changing conventions on the Dream side.

@tungd
Copy link

tungd commented May 2, 2021

This is not directly answer the question but I got away with this by having templates in a separate file, using the Reason syntax and TyXML JSX support.

As a side note, I'd love it if TyXML JSX would become the "endorsed" template solution replacing the current one. I do like the built-in template solution but I'd much prefer Reason/JSX for tooling reasons.

@aantron
Copy link
Owner

aantron commented May 2, 2021

I think TyXML JSX (+ Melange) is basically the "endorsed" solution for Reason, and will be good for a large proportion of users. I have a TODO for making it more prominent in the README. But I don't want to offer it as the basic default, because it is Reason-only, it's an extra thing to learn, it's verbose in places, a bit non-obvious, it doesn't match JS JSX 100%, etc. So, I'd rather offer "plain, completely obvious HTML" for people that don't want to bother with JSX. But it's, of course, a great choice for people already using JSX or who absolutely need to use it in files that they need tooling support for, especially if they are also using it client-side.

@cdaringe You may want to see the TyXML JSX example, if you haven't already.

I also want to more greatly emphasize, in the README, how interchangeable everything in Dream is. And, indeed, it is correct to put "endorsed" in quotes, because Dream doesn't really "endorse" much :)

@cdaringe
Copy link
Author

cdaringe commented May 2, 2021

I did end up finding tyxml from your links! Was surprised that the jsx ppx was reason only, but the html ppx worked fine :)

@thangngoc89
Copy link
Contributor

@cdaringe that is because the JSX part is done by refmt (reason parser + printer). Tyxml has tyxml_ppx for ocaml syntax by the way

https://github.com/ocsigen/tyxml/tree/master/ppx

@aantron aantron added this to the alpha3 milestone Jul 19, 2021
@aantron aantron removed this from the alpha3 milestone Feb 13, 2022
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

4 participants