-
Notifications
You must be signed in to change notification settings - Fork 81
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
Multiline Haddock comments are "normalized" into single-line Haddock comments #641
Comments
Normal comments are not the same as Haddocks. Haddocks do get normalized—this is the expected behavior right now. |
As a user, they look the same to me! I don't mind if this is a "known problem" but I do think it's a problem. |
I can label it as a feature request. (I'd say it is a "feature".) |
To clarify - why is this a problem? |
It means you can't use multiline haddocks. Or rather, you can write them but then they will immediately go away, which obviates one of the main advantages of multiline comments, which is that they're easier to edit. Or consider one of my actual usecases, which is with doctest. Often you'd like to paste the doctest output into the comment when it changes, which is much easier with multiline comments. For my money, I'd rather normalize multiple lines of Haddock content into a multline comment! |
Isn't that one of the points of formatters? You can paste code in whatever shape or form you like. Even snippets of comments. The formatter will do whatever is "hard" to do by hand (indenting everything properly, prepending |
Suppose I have a (morally multiline) comment that ormolu has turned into single line comments:
If I add
then that doesn't parse at all, let alone get reformatted to be a series of single line comments. So I don't see how the formatter is going to do this for me. Maybe I can sell this as a variant of ormolu's rule of "respect the single/multi-line decision of the user, but reformat within that"? |
I think @michaelpj 's example shows that multiline is superior (in terms of functionality) that the current behaviour. Also, what is the downside? |
Not convinced of the superiority. I think single-line is more common and looks better. |
Single-line is probably the better default since that's what the vast majority of Haddock docstrings in existence use. I understand the issue more as a feature request: allowing the existence of just the single-line form. Of course, that weakens the normative power of Ormolu that other teams would want Ormolu to have. |
I agree that single-line is fine for most usecases. I gave an example where it isn't. All I'm arguing is that that's enough to establish that "users may have reasons for using the comment style that they have written", and so we shouldn't change it. (Honestly, I find the preference for single-line comments baffling. Do you not write long comments with diagrams etc in them? Perhaps not: but I do, and hence I spend quite a lot of time editing them and it matters to me quite a lot.) My suggestion for maintaining normativity is what I said before: always emit a multline comment when the content spans multiple lines, since multline comments are superior. But that's controversial ;) I would actually even like it if this applied to normal comments too, sometimes my single line comments grow and I'm too lazy to turn them into multiline comments, it would be nice if the formatter did it for me. |
I don't think I'm understanding everything here, why would Ormolu change a multi-line comment to single line comments? It seems equivalent to changing |
I cast my vote for not 'normalising' multiline comments. I often need to write long comments and I do not want to keep adding '--' at the beginning of every line. More in general, this is a matter of taste, there is no 'right' answer and therefore the preferences of the writer should be respected. |
This still seems unnecessary to me, what is the benefit of changing multiline to single line style comments? This is why I don't see it as a feature request, it doesn't seem to make sense to me to change someone's comments like this. |
It is a normalization procedure to make all Haddocks styled similarly. We'd do the same to normal comments but it is not always possible. I think it is one of the best features in Ormolu. |
You could also say, "I don't see why change anything at all, the author knows better." |
That's true, I just feel like comments are a place to allow more styling since that is what they are for, if that makes sense. |
and the point remains, you can do (and many people do) more powerful things with multi-line comments. They exist for a good reason and Ormolu is removing them. May people use them to good effect, for example https://hackage.haskell.org/package/pipes-4.3.14/docs/src/Pipes.Tutorial.html which is one of the best examples of using Haddocks I think. |
Includes a good summary of why multi-line comments are preferred. |
This prints pipe-style, multi-line Haddock comments using multi-line comment syntax where that is accepted. Note that it is not accepted everywhere. For example, you cannot use it on constructor definitions, so e.g. `operators.hs` remains unchanged. The decision about whether to break after a comment and what styles are acceptable is a bit obscure. I think an datatype enumerating all the places a Haddock coment can occur would be helpful, but I didn't want to bloat this PR too much, so I just added another boolean argument for now. Fixes tweag#641.
This prints pipe-style, multi-line Haddock comments using multi-line comment syntax where that is accepted. Note that it is not accepted everywhere. For example, you cannot use it on constructor definitions, so e.g. `operators.hs` remains unchanged. The decision about whether to break after a comment and what styles are acceptable is a bit obscure. I think an datatype enumerating all the places a Haddock coment can occur would be helpful, but I didn't want to bloat this PR too much, so I just added another boolean argument for now. Fixes tweag#641.
This prints pipe-style, multi-line Haddock comments using multi-line comment syntax where that is accepted. Note that it is not accepted everywhere. For example, you cannot use it on constructor definitions, so e.g. `operators.hs` remains unchanged. The decision about whether to break after a comment and what styles are acceptable is a bit obscure. I think an datatype enumerating all the places a Haddock coment can occur would be helpful, but I didn't want to bloat this PR too much, so I just added another boolean argument for now. Along the way, I tweaked the handling of doc comment content to always strip leading blank lines (it already always stripped trailing blank lines, and sometimes stripped leading ones). This makes it simpler to ensure idempotence. Fixes tweag#641.
Describe the bug
Multiline Haddock comments are "normalized" away. This does not happen for normal multline comments.
To Reproduce
Output:
Expected behavior
Multiline Haddock comments should stay multline.
Environment
The text was updated successfully, but these errors were encountered: