Allow external packages to suggest folds

[savetheclocktower]

Have you checked for existing feature requests?

• [X] Completed

Summary

Someone complained that modern Tree-sitter no longer suggested a certain kind of editor fold. The most naïve implementation of folds in TextMate grammars is very simple and indentation-based, so that line 1 in the following example can fold up lines 2 and 3:

lorem
  ipsum
  dolor
sit amet

You can see this demonstrated even in the plain text grammar.

Folds in modern Tree-sitter are semantic: if your grammar marks certain nodes as foldable, then they'll be foldable. We typically report statement blocks (if consequences, for loops, etc.) as folds — along with function/class definition blocks and similar kinds of things — regardless of the details of their indentation.

But the simpler indentation-based approach can theoretically be made available in any context, and a user might prefer it. We should make fold strategies portable and allow a user to override our default choice for a given grammar, or for all grammars.

What benefits does this feature provide?

Someone in the PHP mega-issue expressed their disappointment that they could no longer fold a function that was completely commented out. The PHP TextMate grammar allows you to do that — which is nuts, but it makes sense, because folding is completely regex-based in TextMate (pattern X means “indent the next line,” pattern Y means “dedent the current line,” etc.).

With this feature, we could allow the user to opt out of the default strategy (which works well for most people) and into these other strategies.

There's another big reason why this might be a good idea: “folding ranges” are part of the Language Server Protocol, so the language server could be another possible provider of folding information. A user might prefer the fold ranges that ide-typescript suggests for them over the ones that we do.

Any alternatives?

I'm not certain there is.

Most folding strategies are mutually exclusive, so we need to pick one. Two different folding providers might want to fold a given line two different ways, so it's not practical to choose which one is better on the fly. That's why we had to abandon an indentation-based approach in favor of our semantic approach; both can't be enabled at once.

The architecture here would be a bit challenging because this screams “service,” yet folding is currently a core editor feature. It'd be easier if folding were a builtin package. So the answer might be to treat it like we did symbols-view: make a package in charge of the feature, but include a builtin strategy as, say, fold-provider-tree-sitter or something. We could also possibly bundle fold-provider-indent and fold-provider-text-mate.

Other examples:

No response