Allow user specified code ranges through markers in the source

[bonds]

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

I want to be able to collapse the long boilerplate of language pragma at the start of my cabal scripts.

Describe the solution you'd like

This block of code is foldable:

-- region "name of the region"
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE BinaryLiterals #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE DeriveFoldable #-}
{-# LANGUAGE DeriveFunctor #-}
-- endregion

See also: https://code.visualstudio.com/docs/editor/codebasics#_folding

Describe alternatives you've considered

Continue to live without this feature. :)

Additional context

I filed a related feature request with the vscode extension: haskell/vscode-haskell#663. If it can be supported at the HLS level, that would be great for all editors, not just vscode, though I imagine there's some work that will need to be done in the extension to take advantage of the feature once it's added to HLS.

IMO this is a pretty low priority feature, but I thought I'd ask just so y'all know at least one person would use it. And in case I'm not the only person interested, it gives others a place find whatever the decision is. Please feel free to close the ticket if y'all aren't interested in implementing this...at least those who find their way to this ticket will be able to find that decision!

And thank you for your consideration and thank you for your contributions to this project, its great!

[fendor]

Indeed and implementing it here sounds like a good first issue. It is a fair amount of work since the latest release of https://github.com/haskell/lsp/ doesn't seem to have the FoldingRange Request implemented

[kokobd]

VSCode already supports custom folding ranges in its latest version: https://code.visualstudio.com/updates/v1_70#_fold-selection.

LSP folding range is another thing. It allows us to provide Haskell-specific folding ranges instead of the default ones inferred from indentation. @sloorush is implementing it in #3058. We may consider to generate a folding range for adjacent pragmas

[kokobd]

In conclusion, we have nothing to do about custom folding ranges, as Language Server Protocol doesn't support it. I recommend converting the purpose of this issue to merging language pragmas in our upcoming folding range support.

[kokobd]

Ah, I somehow misunderstood the original intent. There are three features actually, in VSCode's terms:

1. Manually creating/removing folding ranges on the fly. This is covered by vscode 1.70
2. Folding range markers in source code. This should be handled by HLS.
3. Automatic folding ranges for language pragmas. This should be handled by HLS. I will create another issue for that.

[michaelpj]

Folding range markers in source code. This should be handled by HLS.

We could do this, but I'm not sure if we should. I think the language server's job is to report folding ranges that make sense based on the language. Adding custom folding ranges specified by the user seems like it's probably the client's job.

[kokobd]

To clarify, the second feature mentioned is about adding markers to the source code, for example:

-- #region
myPortionOfCode :: Int
-- #endregion

And this is language dependent. We need to parse Haskell source code in all clients (VSCode, vim, emacs, etc), and make sure they behave the same, which is practically impossible to maintain in my view. And if different clients use different markers, that will lead to multiple markers co-existing in the source code.

Though, the analysis above makes sense only if range makers do. Would some teams allow submitting these markers to version control? People do submit something like @SupressWarning to inform linters to my knowledge.

[kokobd]

2. Folding range markers in source code. This should be handled by HLS.

I came across this extension in the VSCode marketplace: Explicit Folding