Excessive whitespaces inserted for `..`

[MahdiBM]

This behavior is specially annoying with sourcekit-lsp's experimental on-type formatting enabled.

Current behavior with one dot:

echo "String(decoding: data, as: UTF8.self)" | swift format format -
String(decoding: data, as: UTF8.self)

Doesn't touch the code, which makes sense.

Current behavior with 2 dots:

$ echo "String(decoding: data, as: UTF8..self)" | swift format format -
String(decoding: data, as: UTF8 .. self)

Inserts a whitespace before, and a whitespace after ...

This simply should just not happen. Swift format should take no action on the code above.

I experience this behavior when I'm trying to add something to the code.
For example when I have my.thing then I write my..thing so I can continue to write my.some.thing, but the on-type formatting turns my..thing into my .. thing which is not the end of the world, but definitely undesired and takes steps to reverse.

There is also a question of should on-type formatting be triggered at all in this situation?

The way on-type formatting works is that we register characters for which we should get notified of code changes in the specific changed line,
and when a notification happens, sourcekit-lsp tries to format that line using swift-format's relatively-new selection-formatting support.
. is registered as one of those characters so that triggers the on-type formatting, and then swift-format messes up the formatting when asked to format the line.

Possibly both. I don't see why swift-format should exhibit this behavior, but at the same time maybe sourcekit-lsp should not watch for . insertions for on-type formatting.

The current list of characters that sourcekit-lsp watches for are inspired by Xcode (see this comment), so perhaps we should just fix swift-format and move on.
Off-hand I can't tell what watching for . can be helpful for, but that doesn't mean it's not helpful.

cc @ahoppen

[allevato]

Current behavior with 2 dots:

$ echo "String(decoding: data, as: UTF8..self)" | swift format format -
String(decoding: data, as: UTF8 .. self)
Inserts a whitespace before, and a whitespace after ...

This simply should just not happen. Swift format should take no action on the code above.

The code you've cited is syntactically valid Swift code—the .. is treated as an infix operator, and the formatting rules say to put spaces around infix operators. In isolation, swift-format is doing the correct thing unless we tried to look at the surrounding context to detect things that user was typing but didn't necessarily mean. Down that path usually lie dragons.

There's no easy way today to say "the input is syntactically valid but I'm not done with it yet". If SourceKit-LSP is calling into swift-format during typing to apply changes (I'm not familiar with the SK-LSP implementation), then we would need a way to pass in additional context that says there are edits in progress and somehow be less opinionated about some of the choices on that line or in that general region, before finally doing the full format.

[MahdiBM]

That's possible and easy to do from sourcekit-lsp side, if we ever decide on just passing a flag.

That being said, would it be reasonable for swift-format to just have such setting enabled based on whether or not "selection formatting" is what is swift-format is performing (aka when a range is passed from CLI)?

[allevato]

We can't assume that just using range formatting means you want the interactive behavior you've described. Consider the situation where you have a 1000 line file and you edit a single function in it. A hypothetical git-swift-format could have git pass the range of the modified part of the file to swift-format so that it only reformats the code in the modified range, but you would still want swift-format to apply all valid formatting to that range, not just some vaguely defined notion of "formatting except what might be disruptive during interactive editing". Interactive editing/typing is a very different use case from other formatting tasks (range-based or otherwise) and we shouldn't try to guess the intention here.

[MahdiBM]

Ok an "interactive" option sounds good to me.

[MahdiBM]

@allevato .. is not an actual operator though? I've never seen it in a code. I can see the stdlib/swift-foundation don't declare such an operator, so maybe we should just not assume this is an operator?
Or maybe you're saying that SwiftSyntax identifies this as an operator and swift-format just follows that?! If that's the case then ok, but otherwise maybe we shouldn't assume .. is an operator since that would be a widely inaccurate assumption?

[allevato]

Swift allows custom operators to be defined, so .. could be an operator. The point is that the parser claims that it's one.

We're sort of already in a not-totally-accurate situation because we make a couple assumptions:

• We only do operator folding with the default set of operators, so custom operators are treated as having unknown precedence/associativity in situations where we want to consider that (when wrapping long expressions).
• We treat range formation operators like ... and ..< differently than other operators with regards to surrounding whitespace.

Both of these situations could be improved by letting users who frequently use custom operators define their behavior in their configuration, but there's never been a high demand for it.

Anyway, all of that is sort of irrelevant, really. If .. were the only situation where this kind of awkward-formatting-while-typing situation would arise, maybe we could consider special casing it. But it won't be, and we should focus on the broader problem of how to handle interactive formatting, not limit our discussion to one specific token.

[MahdiBM]

If .. were the only situation where this kind of awkward-formatting-while-typing situation would arise, maybe we could consider special casing it. But it won't be

I do think it would really be the only or one of the only. Probably actually just the only.
. is a very special character in Swift. It's the character to access properties/members of a type. So making an special case for it does sound fine to me.

[MahdiBM]

On another thought ... I think swift-format doesn't format invalid code, right? So if we teach swift-format that .. is indeed invalid, that would also solve the issue in a away because then swift-format will simply refuse to format that code.