Module name codelens suggestion always present (with flickering)

[azuzunaga]

The codelens hint at the top of the editor always suggests a module name if the existing module name doesn't match the dir/filename structure. However, the hint collapses and is displayed again while typing, making the editor scroll up and down the screen.

Is there a way to turn module name hints off? It is possible to disable all codelens hints via the settings, but I'd like to preserve the other hints.

Here is a screen recording demonstrating the jumping around:

[jneira]

Hi thanks for opening the issue. There is a way to disable plugins but it still is not documented (#1433). To disable the module name plugin you can add the following json snippet where your editor put the lsp configuration (in vscode .vscode/settings.js)

haskell.plugin.moduleName.globalOn": false

[ndmitchell]

@jneira this sounds like a bug in the module plugin though. I'm not totally sure why it wants to rename the module (seems dubious to me), but it should definitely not flicker as the code goes in/out of parsing, but should be using the last stale correct value to base its suggestions on.

[jneira]

yeah, you are right, the code lens should be stable

[azuzunaga]

@jneira, thanks for the quick response! Adding the setting did the trick. Appreciate the help.

[jneira]

@azuzunaga thank you for trying and confirming it works, i am gonna let this open to track the solution of the disturbing flickering

[jneira]

maybe @tittoassini could have some time to take a quick look 🙂

[tittoassini]

The code seems to have changed significantly since I wrote the initial version so I might not be the right person to ask.

Anyway I had a quick look and the problem is what @ndmitchell suggested, as the code become unparsable the code lens disappears.

[tittoassini]

It might be just a matter of changing this line:

141 pm <- MaybeT . runAction "ModuleName.GetParsedModule" state $ use GetParsedModule nfp

to

141 pm <- MaybeT . runAction "ModuleName.GetParsedModule" state $ useWithStale GetParsedModule nfp

I will have a look soon.

[tittoassini]

Yes, that solves the problem.

Of course if we use stale information, that might lead to incorrect code actions.

If for example:

• you edit the file causing a syntax error
• module is now unparsable but the plugin will still display its previous suggestion (say "Set module name to X") before an incorrect "module Y where"
• insert, say, an empty line before "module Y where"
• click on the "Set module name to X" code lens, the change is applied on the previous position of "module Y where" :-)

But that's life for you (btw this happens with all plugins that rely on stale info, for example the 'imports' one).

[tittoassini]

So what you want? What you really really want?

Correctness or Aesthetics?

Can't have both I am afraid (or maybe you can? any suggestion?)

[jneira]

Hmm both if possible :-)
But i doesnt seem so serious even if the worst case you described, user clicks the code lens and it is inserted, their bad :-P

[tittoassini]

I see that useWithStale returns a PositionMapping, is that meant to be used in conjunction with a diff to update the position of a code lens edit? that would fix the problem (a minimal problem for sure, possibly not worth fixing).

I am far from my computer for a few days, I will look into this again next sunday, in the meantime any suggestion is welcome.

[michaelpj]

The recommendation here still seems good, just need someone to implement.