suggestion: don't inspect quasiquote contents for linebreaks

[aryairani]

Is your feature request related to a problem? Please describe.

I have a number of blocks like this:

Ucm.runTranscript c1 Ucm.Runtime1 [iTrim|
    ```ucm
    .> alias.type ##Nat builtin.Nat
    ```
  |]

that get formatted to this, putting each argument on a new line, even though they were arguably all on one line initially:

Ucm.runTranscript
  c1
  Ucm.Runtime1
  [iTrim|
    ```ucm
    .> alias.type ##Nat builtin.Nat
    ```
  |]

Describe the solution you'd like

I think the additional linebreaks shouldn't be added when multiline quasiquotes appear at the end of a line.

Describe alternatives you've considered

I know I could use {- ORMOLU_DISABLE -}, but I don't really want to disable ORMOLU altogether.

Let me know what you think!

[mrkkrp]

In general, every function argument in a multi line function application will be on a separate line. Why would quasiquotes deserve special treatment?

[aryairani]

I agree with the rule. In my mind though, it's not a multi-line function application; it's a single-line application where the final argument happens to be a kind that has totally separate syntax treatment, as quasiquotes do.

[aryairani]

In general, every function argument in a multi line function application will be on a separate line. Why would quasiquotes deserve special treatment?

@mrkkrp quasiquotes deserve special treatment because the thing they contain isn't Haskell, and isn't bound by Haskell formatting rules. What do you think about this?

[mrkkrp]

I think that in Ormolu our general rule is not about the "type of content" but just about the spans: are they single-line or multiline? If you have e.g. a multiline string it'll be treated as a multiline object even though it is just a string and not an expression. I think it's a pretty good principle and it allows us to achieve consistent results without introducing a classification other than single-line/multiline.

[aryairani]

it allows us to achieve consistent results without introducing a classification other than single-line/multiline.

That makes sense. I hope you'll consider it in the future.

[tbagrel1]

I think that in Ormolu our general rule is not about the "type of content" but just about the spans: are they single-line or multiline? If you have e.g. a multiline string it'll be treated as a multiline object even though it is just a string and not an expression. I think it's a pretty good principle and it allows us to achieve consistent results without introducing a classification other than single-line/multiline.

If #830 is merged in a near future, we will get the same kind of behaviour with operator chains. If both of these conditions are satisfied:

• all operands of an operator chain start on the same line
• the last operand is multiline with exprPlacement lastOperand == Hanging

Then the operators stay on the same line (see your comment here).

So maybe it would make sense to reconsider this issue when #830 is merged to stay consistent?

[aryairani]

Now that #830 is merged, is it time to reconsider this issue?

without introducing a classification other than single-line/multiline.

Perhaps you still wouldn't need a classification other than single-line/multiline; just consider quasi-quotes as single-line.

[aryairani]

FWIW I just noticed that when the final argument to a function is a multi-line lambda, that does not cause the entire function call to be formatted in the multi-line style. Perhaps quasi-quotes could use this same mechanism?

[brandonchinn178]

Seems like the ask here is to include quasiquotes as a hanging construct, similar to do and lambdas.

Possibly related:

• https://github.com/tweag/ormolu/issues/692
• https://github.com/tweag/ormolu/issues/514