[Feature Request] append language extension to language pragma list in the 'add extention' codeaction

[goolord]

I realize that I am one of very few haskellers who actually want this so I am willing to implement it myself 😅

basically, it's typical for me to put all of my language extensions in one language pragma like so

{-# LANGUAGE
    OverloadedString
  , GADTs
#-}

under some criteria like
length languageExtensions == 1 && length (head languageExtensions) > 1
I would like the add "LanguageExtension" codeaction to append to this list

currently the codeaction would do something like

{-# LANGUAGE
    OverloadedString
  , GADTs
#-}

{-# LANGUAGE ScopedTypeVariables #-}

[jneira]

thanks for the proposal, i think it makes sense, as ghc let's you arrange pragmas this way
moreover the conditions you mentioned would make it non intrusive (but I would create a new code action: append Lang extension or something alike)
so a pr would be welcomed 🙂

[ndmitchell]

With the increasing move towards auto-formatting, I suspect that not formatting your code the way everyone else does is increasingly going to be a niche activity. Would it really be that terrible to just format it like everyone else? FWIW, I used to follow the all pragmas in one block, and have since decided I was wrong, and follow convention. I don't think the convention is particularly good, but I do think that going against everyone else is worse.

My concern is that the list of code actions can often be quite long, and the more you add there, the harder it gets to actually use. You could make it a configuration, but a configuration is going to only be used by a few people, so the testing vs benefit trade off is different.

[goolord]

to your first point, i completely empathize. stubbornly, in my small libraries, i am unwilling to give up control over the form and aesthetics of my code, though.

but yes, as a user of hls I'm also mildly opposed to introducing a new code action for this specific use case (which is why i suggested branching on some predicates).

the list of code actions can often be quite long

rust-analyzer's barrage of code actions annoys me to no end, so I'm cognizant of the problems this can cause, haha

[jneira]

My concern is that the list of code actions can often be quite long, and the more you add there, the harder it gets to actually use. You could make it a configuration, but a configuration is going to only be used by a few people, so the testing vs benefit trade off is different.

Well, couldnt we use the predicate to emit the code action with no further configuration? (instead altering the actual one). That would be totally transparent for "conventional" (:-P) users

[isovector]

My opinion here is that HLS should be very stubborn about its formatting rules. The world we all want to live in is one where our tools show us code in our preferred style, regardless of what the bytes look like, and without getting us into fights with other people who disagree about our preferences.

Rather than putting specialized formatting rules in HLS for the pragma styling, I'd suggest we delegate that to a code formatter. I'd imagine one of them already supports this, and if not, it probably wouldn't be hard to add.

By punting this out to a formatter, it means:

• we don't annoy users by forcing them to choose which of two identical-up-to-formatting code actions to run
• we keep our number of code paths smaller
• HLS can stay out of the business of dealing with styling

Formatters can already be run automatically on file save, so I don't think this will be a usability concern.

[goolord]

HLS can stay out of the business of dealing with styling

imo HLS is already in the business of dealing with styling #1726 #1731

I feel like my suggestion is rather innocuous. it does not introduce a new code action (jneira made that suggestion), and ostensibly would not introduce a notable amount of complexity

though, I'm not that invested in this so if there's still a strong opposition I will close this issue and maybe maintain a fork with this behavior for personal use 😅

[jneira]

mmm imo rearrange pragmas would be in the limit of a formatter responsibility, it would have to modify existing delimiters, and I would be somewhat surprised if a formatter will do it.
I expect formatting can modify whitespace but not remove or add delimiters.

But maybe I have a wrong concept about that. 🙂

[pepeiborra]

Stylish Haskell does regroup Language pragmas automatically.

[jneira]

@goolord sorry, but i removed the pr-welcome cause there is no consensus about.
A possible way to add the feature in a clean way could be make a new plugin. It is relatively easy to assemble a hls executable with an additional plugin and the feature could be distributed to other users.