Automatically try to remove scopes as if they're token, line, block, file if they have no removal behaviour

[pokey]

Most of our tree-sitter scopes don't remove newlines, and some of them don't remove spaces. We'd like a way to make them all automatically remove the appropriate whitespace

I would argue that we should detect if something stops at a line boundary and use newline delimiter if so.

Implementation

Where

Let's start by putting it on SyntacticScopeTarget

What

If target has leading or trailing range, we use today's behaviour.

Otherwise, we see if the "core removal range" corresponds to the entire file, then falling back to block, then line, then token. If it corresponds to one of these, we forward calls to removalRange to the upgraded target

The core removal range will be the value passed in to removalRange in constructor, otherwise content range.

Other thoughts

Alternately we could add this implementation to BaseTarget, so that things like SyntacticScopeTarget will get it, but not get LineTarget, TokenTarget, UntypedTarget (?) will override it, but let's start with SyntacticScopeTarget for now

[AndreasArvidsson]

Do you want this behavior only for pour or also for bring? Should some scopes types be omitted? Because now when we have textual item scope "pour item" should definitely not insert a line just because it is the last token on the line.

[pokey]

If something is the last token on the line it will not count as a line. It needs to start and end on line boundary

It will also only be if the scope type has no explicit delimiter set, so wouldn't affect item for that reason as well

[AndreasArvidsson]

I guess for scope types that have no specific insertion delimiter this could work. How will you handle multiline targets? Check both first and last line? Leading and trailing white space will be omitted from the line calculation?

[pokey]

Yep!

[pokey]

I think we can also consider detecting we're a block and set it to \n\n, though not quite as critical as the newline one. That one gets me because it feels like a regression in situations like this one

[pokey]

This one is also super annoying for "section" in markdown, eg "clone up section"

[AndreasArvidsson]

The current solution for these is of course that they have the wrong delimiter. Section should definitely not insert or remove as a token.

[pokey]

Yeah maybe for now let's just add them to that switch statement, but I do worry it's going to start feeling like a game of whack-a-mole

[AndreasArvidsson]

Agreed. We should definitely have a proper look at an alternative solution. But just for now I think we should just add them to the delimiter list.