Add an option to disable the code lens about vscode-reasonml

It is possible to disable the code lens feature by setting "editor.codeLens": false in the editor preferences. That will turn the feature off for the entire editor. I could probably add a separate option just for this extension and maybe have a command to toggle it on or off.

I'm not really sure how to adapt it so that it can be enabled or disabled locally though. Do you mean local to a compilation unit (file) or to a module or something else? Can you give me an example of where you would want to use that?

[Khady]

I'm playing with the editor.codelens option for now but I don't find it super convenient. Locally could be the file or for the whole extension. If it can easily be turned on and off, there is no need for a very small granularity. I wanted to say that a command would be enough to hide/show the code lens without having to go back and forth in the configuration panel. The usual place I would like to use this is in files with a lot of top-level values. I have for example a file at work with maybe 100 lines that all contains a simple `let name = create value "name"`. In this case, the code lens doesn't bring much and take actually half of my screen. I have a few extensions like typescript and git that offer configuration options for the code lens. Maybe it can be used as example. This is not a very important feature request, mostly for comfort sometimes. If you don't think it's too hard, maybe it can be a good opportunity for me to do a first contribution.

I see what you mean. I agree that the code lens feature is a little bit too noisy in some cases like with a lot of simple top level bindings.

I will add a separate option to allow disabling the code lens just for this extension.

Other than that, probably the best way to handle this would be to store a "code lens enabled/disabled" setting in the LokiJS database which I am currently just using for symbol-related metadata. That way you could remember the code lens setting on a per file basis. That data could also be persisted across editor sessions if it's in a database. I don't currently write the db to file but this might be a reason to start doing that.

If you wanted to try to add a setting to allow disabling this feature just for this extension, you would first need to add a new property like here. Next, in the code lens function here you would need to do a check for that setting (see session.settings). Doing this shouldn't be hard. Integrating with the database like I described above would take more work.

I've been thinking about this more and I believe it might be possible to change how the code lens works so that it can be disabled on a per-item basis. I think I would find that preferable to just disabling it for an entire file since I tend to use a lot of nested and/or recursive modules in my projects.

To facilitate this, we would need to make the hypothetical code-lens-toggle command take an optional range parameter. We would then use merlin to fit that range to an item (e.g., a module or let), and store a isCodeLensEnabled property in the database (which would default to the global code lens preference if unset). When we refresh and submit the code lens data to the editor, we would filter out all the items that should be ignored. We could also have some sort of indicator like a gutter icon so that the user knows the code lens is locally disabled for that region.

Doing this would certainly add complexity to the code lens functionality but for the most part I think it would be straightforward to support. The main downside is that this idea makes some of the optimizations I had planned for the code lens functionality (caching, etc.) more difficult to implement. But performance doesn't seem to be a real problem at the moment anyway so that's probably okay.