Do not suggest any hole filling if there are too many suggestions

[expipiplus1]

Perhaps it would be possible to use the type of the hole to make a
better limiter here, but this is better than the current situation I
think.

Closes haskell/haskell-language-server#532

[jneira]

I wonder if we could detect in some way the type is ambiguous, or if there is a bigger, fixed, threshold in that case.

[expipiplus1]

The test which tests that show is suggested for the hole _ :: Int -> String fails, because too many holes suggestions are generated (hence none are reported).

The test is:

globalConvert :: Int -> String
globalConvert = undefined

globalInt :: Int
globalInt = 3

bar :: Int -> Int -> String
bar n parameterInt = _ (n + n + n)  where
  localConvert = (flip replicate) 'x'

foo :: () -> Int -> String
foo = undefined

And the suggested holes are:

7. replace _ with localConvert
8. replace _ with globalConvert
9. replace _ with prettyPrint
10. replace _ with mempty
11. replace _ with showGhc
12. replace _ with show
13. replace _ with discard
14. replace _ with bar _
15. replace _ with foo _
16. replace _ with ($) _
17. replace _ with pure _
18. replace _ with join _
19. replace _ with return _
20. replace _ with (!!) _
21. replace _ with unfoldr _
22. replace _ with id _
23. replace _ with head _

I really like the suggestion of filling a hole with id _ or ($) _! (reminds me of this: haskell/haskell-language-server#520)

I think that although this is a good example of why this is useful, it might not be good to use until holes are either suggested with a bit more restraint, or could be sorted by likely usefulness (and in that case only the top n holes could be reported)

[pepeiborra]

Ghc flags allow to set the max number of hole suggestions. The code is in D.I.GHC.Compat

[pepeiborra]

5 seems a bit low. I would go for something like 15. Can we make it user configurable?

[expipiplus1]

If it can be configured by ghc flags, then perhaps this is better left to cabal.project.local or something.

[jneira]

But your limit, the one pepe asked for, is now different from the ghc flag, no?
You can set 100 in the flag but you will not show suggestions if they are greater than 5.

[expipiplus1]

oh sure, it's slightly different; tbh I'd be happy with either

[expipiplus1]

I selected 5, because if the selection isn't instant, i.e. at a glance, then I'd be better off just typing what I want (I could certainly be blind to other's preferences or use-cases here!). Tbf I have absolutely no UX research behind this!

This site suggests that the "Total Number of words made out of [a] Glance = 50"!!!

[pepeiborra]

I think the limit (be it 5 or 15) should be moved to the GHC flags that we set in GHC.Compat, and make sure we don't override a user value.

[expipiplus1]

That's fine, although as mentioned above these do do subtly different things, and as this is it's more of a filter to overwhelming users with suggestions. With the ghc limit is there any rhyme or reason to what holes make the cut if there's a limit?

…

On Fri, Oct 30, 2020, 5:01 PM Pepe Iborra ***@***.***> wrote: I think the limit (be it 5 or 15) should be moved to the GHC flags that we set in GHC.Compat, and make sure we don't override a user value. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#888 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXDQ7IDER3YZNCD2XBDSNJ6DJANCNFSM4TBXMUPA> .

[pepeiborra]

GHC flags allow specifying the sorting algorithm too

[pepeiborra]

The ghcide Github project is becoming archived and merged into https://github.com/haskell/haskell-language-server

This PR will need to be reopened in the HLS repo. To do that, create a new branch from HLS HEAD in your HLS repo and do:

git remote add ghcide https://github.com/georgefst/ghcide.git
git fetch ghcide
git merge ghcide disable-warnings

Thanks!