HLS needs a concept of "features" as well as "plugins"

[michaelpj]

HLS's plugin model has been pretty successful. It has helped us a lot with modularity, and clear divisions of responsibility for maintenance. It has some issues (lines between plugins are unclear, infrastructure for merging everything can be awkward), but has overall been great... for maintainers.

But I would argue that it has not been great for our users. This is because the plugin organization tends to leak into the user experience:

• Config options are arranged by plugins, and offer options like "turn off all the code actions for this plugin"
• The user documentation makes frequent reference to plugins, for example in telling users what is and isn't supported

But this is pretty meaningless to users. What, exactly, does hls-refactor-plugin do? Do I want it to be on? What would happen if I turn its code actions off? Who knows??? Even if we document this, the granularity is not good. hls-refactor-plugin, does quite a few things. The user might want to turn off some but not all of its code actions.

I claim that we are lacking a concept of "thing that the user cares about", and I propose to call this a "feature". I'm not sure I have a clear definition of "feature", but I think the pragmatic definition of "something the user might care to think about" is a good guide.

A single plugin may provide many features. For example, the cabal plugin provides:

• Diagnostics in cabal files
• Completions in cabal files
  • Indeed, it provides completion of different kinds of things in cabal files. We might view these as separate features, or sub-features, I don't know.
• Various code actions to do things in cabal files
  • From the user's perspective, these are mostly all separate features. In some cases multiple code actions might fit together as one feature, for example the family of code actions for adjusting import lists.

Features do not necessarily consist of a single method handler or similar. The handler might require that a rule be present. Or a group of code actions might be so tightly bound that it makes sense to talk about them together.

Features are a much more natural place to hang configuration. "Do you want to turn off the code actions for adjusting explicit import lists?" This is a question that might actually make sense to a user! (although arguably it's still too vague... maybe we would want to break it down into the specific pieces?)

---

Okay, but what would we actually do? In fact, I think we don't need to change too much!

• The concept of Plugin that we have in the code could function just as well as a Feature: it has the capability to include multiple handlers and rules (which we want!) and has a place to hang configuration. We would just need to do some renaming and tweaking.
• We don't necessarily need a code-level concept of a "plugin". We might be fine considering a plugin to be just a cabal component that exports several Features.

At that point you can look at what I'm proposing as:

• Making our plugins much more granular, and having many of the current plugin components export multiple ones
• Banning discussion of the package-level "plugins" and only talking about the feature-level "plugins" in documentation and user messages.

[michaelpj]

Other things to think about: maybe we want some kind of hierarchy here, so we can group together all the cabal-related features together when e.g. creating config options. We could call a group of features a "plugin" :D