#2794 Initial HIndent support

[uhbif19]

I am not quite sure if I am using HIndent API correctly, but it does format something.

Currently I do not handle config, cuz not sure where to call getConfig :: IO Config (https://github.com/mihaimaruseac/hindent/blob/master/src/main/Main.hs#L77).

There is some story with [Extension] param. As far as I understand providing Config should be enough. (https://github.com/mihaimaruseac/hindent/blob/master/src/HIndent.hs#L71)

[pepeiborra]

You will need to add the test suite to the GitHub CI test.yml

[pepeiborra]

Currently I do not handle config, cuz not sure where to call getConfig :: IO Config (https://github.com/mihaimaruseac/hindent/blob/master/src/main/Main.hs#L77).

You can setup a handler for the LSP Initialised event and call it there:

haskell-language-server/exe/Main.hs

Lines 54 to 57 in 65fbc5e

	{ pluginNotificationHandlers = mkPluginNotificationHandler LSP.SInitialized $ \_ _ _ _ -> do
	env <- LSP.getLspEnv
	liftIO $ (cb1 <> cb2) env
	}

[michaelpj]

I think it would also be fine to call it in the handler, that's what the stylish-haskell plugin does, for example.

[uhbif19]

Looks like some yak-shaving required to make this to build: mihaimaruseac/hindent#583

[uhbif19]

Looks like getConfig is not exported from hindent. So I can either try to change hindent or copy getConfig with Path.File and bunch of dependencies. Which way is better?

[michaelpj]

So I can either try to change hindent

That would be ideal. Maybe open an issue and see what the maintainer thinks is the best way of doing it. People are typically happy to be included in HLS, so hopefully you'll get a response :)

[uhbif19]

Issue created: mihaimaruseac/hindent#585

[michaelpj]

Looks like upstream isn't very responsive at the minute. Perhaps copying getConfig is the least bad option in the short term?

[uhbif19]

@michaelpj Maybe I will write universal config-looking function working for both HIndent and Stan? Where should I place it?

[michaelpj]

I don't think that necessarily makes sense since different projects have different config mechanisms. As much as possible we should use upstream.

[uhbif19]

@michaelpj

getConfig was added and tests use configuration file now.

Where is still git-dependencty in cabal project, cuz build fix is not released yet.

[michaelpj]

LGTM, just a couple of comment requests.

[michaelpj]

Link to the ticket and explain that we can remove this once upstream gives us a better way.

[uhbif19]

Done.

[michaelpj]

🙈

[michaelpj]

Sorry, just one last thing I missed before - docs! Can you add this plugin to the "Features" doc and also add a line for it about GHC version support on the GHC version compatibility page.

[uhbif19]

@michaelpj Circleci CI tasks are stalled. Can I do something to fix this?

[michaelpj]

Not sure tbh!

[pepeiborra]

@uhbif19 are you able to wrap up this PR?

[uhbif19]

@pepeiborra Will try to fix fails in next couple of days.

[uhbif19]

@michaelpj Another strange CI (bug?): "Could not find a usable config.yml because you deleted the CircleCI OAuth app."

Do you know anything about it?

[michaelpj]

You are oddly cursed, nobody else seems to have trouble with CircleCI 😅

[michaelpj]

Okay, looks like a genuine failure on stackage-lts16 now.

[uhbif19]

This looks like hindent problem, I created an issue: mihaimaruseac/hindent#589

[uhbif19]

Now all CI jobs are getting stuck.

[pepeiborra]

@uhbif19 are you able to resolve the conflicts? Hopefully that will unstuck CI

[uhbif19]

Lol, I forgot about this PR. Does anyone need it?

[michaelpj]

Nobody has asked for it since this PR has been open, so I think it's not that popular and probably not worth it.