Comments move to the same line as the following declaration about smlfmt HOT 10 CLOSED

Here's a couple more examples of issues. Multiline comments are handled differently than normal comments. IIRC, the pass which inserts comments also ungroups things in some cases. We should take a close look at this.

INPUT

(** this is a multiline comment
  *)
structure A = B

(* this is a comment *)
structure C = D

OUTPUT

(** this is a multiline comment
  *)
structure A
  =
  B
 
(* this is a comment *) structure C = D

from smlfmt.

It just occurred to me that we can make our lives easier here with Rigid. Multiline comments need to be ungrouped to prevent flattening. This is currently done in an adhoc way. We could instead just make them rigid. 🚀

from smlfmt.

@HarrisonGrodin some progress on this. I implemented this idea:

Adding a pass to pull comments as high up as possible (without crossing a source token) might help

It worked great. Now the formatted output looks good for these examples:

structure S =
  (* A *)
  struct
    (* B *)
    val x = 0
    (* C *)
    val y = 1
  end
(* D *)
val z = 2
 

(** this is a multiline comment
  *)
structure A = B

(* this is a comment *)
structure C = D

from smlfmt.

There's still one case which seems to not quite do the right thing:

INPUT

val x =
  if b then
    yah (* comment *)
  else
    nah

OUTPUT (max width 20, to force ungrouping for purposes of this example)

val x =
  if b then
    yah
  (* comment *)
  else
    nah

I know why it happens, but it's not clear what the best solution is. Comments are inserted "before" each token, and the comment retains some properties of the token it attaches to, e.g. its indentation. The comment above attaches to "else".

It might seem like we could fix this by trying to detect which token it should attach to. But this is not so straightforward.

Suppose we had this as input:

val result = (* when b, say hello *) if b then hello (* otherwise, say goodbye *) else goodbye

The formatter produces this, which we hopefully both agree is "correct":

val result =
  (* when b, say hello *)
  if b then
    hello
  (* otherwise, say goodbye *)
  else
    goodbye

from smlfmt.

Yeah definitely. I'm leaning towards leaving this as the default behavior.

There are definitely people out there that prefer writing comments after expression/declarations, rather than before. So, perhaps not ideal. But good enough for now I think!

from smlfmt.

Ah interesting. The prettying pass which inserts comments locally decides whether to insert above or beside the next token. This also interacts with grouping. I did a quick and dirty implementation with a simple heuristic, but this clearly needs to be revisited.

from smlfmt.

I also have a guess that the formatting issues with comments are caused by individual comments appearing "deeply nested" within the doc structure. Adding a pass to pull comments as high up as possible (without crossing a source token) might help.

from smlfmt.

Wow, that looks incredible!

There's still one case which seems to not quite do the right thing:

How bad would it be to consider this the correct behavior? Presumably,

val x =
  if b then
    (* comment *) yah
  else
    nah

would format to

val x =
  if b then
    (* comment *)
    yah
  else
    nah

Perhaps this behavior is desirable, since it gives users a simple way to understand what comments are attached to?

from smlfmt.

If you agree, I think we can close this issue :)

from smlfmt.

Agreed!

from smlfmt.