My pragmas keep shouting at me

[emilypi]

Hey all, you have a great project here, and I'm liking the progress. My only gripe so far is that whenever ghcide prompts me to add an extension, it inserts a very loud pragma LANGUAGE or INLINE or MINIMAL etc. This is a very low priority feature request, but you could add the ability to write lower-case extensions so that I can have an indoor conversation with my compiler?

Thanks

[ndmitchell]

Since Haskell users tend to default to SHOUTY by a significant margin, I think it would have to be a preference - but not an unreasonable one to add. Our preference handling is not something we've invested much in, so that might be a prerequisite.

[emilypi]

Point me in the write direction and I can do it for you guys 😄

[wz1000]

The code action is generated here: https://github.com/haskell/ghcide/blob/master/src/Development/IDE/Plugin/CodeAction.hs#L512

The preferences mechanism is a bit more involved and doesn't currently work, haskell/ghcide#857 should fix it.

[pepeiborra]

Easiest thing to do is to generate two code actions, one SHOUTY and one not

[alanz]

Easiest thing to do is to generate two code actions, one SHOUTY and one not

We already have too many, cluttering the UI

I think it would be better to make this configurable. Default as current, but you can set it.

[wz1000]

Another option would be to detect the style being used in the file, and then respect that. This way we do not need a configuration option, and things just work (except for the first time you add a language extension).

[ndmitchell]

I suspect the "ideal" solution would be a setting, with three values - SHOUT, whisper and FollowThisFile.

[georgefst]

haskell/ghcide#897 uses OPTIONS_GHC in all caps as well. Just another one to bear in mind.

[michaelpj]

Generally I think we're trying to avoid configuration, and nobody else has asked for this, so closing.

[georgefst]

Generally I think we're trying to avoid configuration

Why exactly? I don't think I've seen any discussion around that. I am aware that adding options is currently quite onerous, from how long it took to resolve #2827. But there are various suggestions in linked threads about how that situation could be improved.

In general, I'm not sure about the wisdom of closing unresolved issues like this, as opposed to just marking them low-priority. I do still care slightly about this, and presumably so does @emilypi. (This is essentially the "stale bot" debate, where I can see the logic in tagging "stale" issues, but not in auto-closing them as some do.)

[michaelpj]

Why exactly? I don't think I've seen any discussion around that.

Perhaps it's folklore. But generally: configuration means a bigger state space, means more to test, and gives users more choices (which is not necessarily good for them). If it's possible to get something that's good enough and doesn't require configuration, I think that's usually better (sometimes it's not possible!).

In general, I'm not sure about the wisdom of closing unresolved issues like this, as opposed to just marking them low-priority.

Okay, we can keep it open! But I've generally found that issues that people care about even slightly tend to have some additional comments on them. This one is very old, and my reading of it was that nobody except @emilypi cared about it (you commented but I wasn't sure if you were in favour!).

The reality is that we have a lot of issues for things that somebody maybe wanted once. I'm leaving a lot of them, but I am trying to cut down on ones that are particularly dead or don't seem popular.