Improve `PacmanUpdates`

Recently, I've seen the usefulness in knowning whether one of the pending updates is a kernel update (which means we should most likely reboot after next system update), and also whether the running kernel is older than the installed kernel package (which means we've probably not rebooted yet), so I thought I should update this plugin.

However, the feature of knowing whether a kernel update is contained in the available updates requires that one knows the kernel package name, so that's to be a `String` input to the plugin. But one might not want to pass it, and be happy with just the detection of whether the running kernel is older than the installed one.

Since recently, I've been studying type families and also come across pattern synonyms, I thought I could leverage these, so I thought I could parametrize the plugin over kind `Bool`, and branch on it to provide the different APIs; then I could use type synonyms to lift the burden of having to use type application at the user code.

Furthermore, rather than still customizing the message by asking the user to provide `String`s for the various cases (0 updates, 1 update, 2+ updates), I thought it was better to ask the caller to provide a function that accepts the relevant inputs (`Int` number of updates, `Bool` telling whether such and such) and turns them into a `String`.

With this change, I'm

  - renaming the previous type `PacmanUpdates` to
    `PacmanUpdatesDeprecated`
  - deprecating such type (with a pragma and by printing a clickable
    note in the plugin text) with the intention of deleting it in a year
    from now,
  - preserving its data ctor's to avoid breaking existing code right
    now,
  - creating a new `PacmanUpdates` type that is parametrized over kind
    `Bool`
    - the `True` instance allows passing the name of the kernel package
      that the plugin uses to detect whether there's a pending kernel
      update
    - the `False` instance doesn't,
    - accordingly the two instances accept from the caller a printing
      function with different signature (see haddock comments for
      details),
  - hiding (i.e. not exporting) the constructor of such new type,
  - provided pattern synonyms to more conveniently create a
    `PacmanUpdates False` (for `PacmanUpdates True` is just the same as
    the ctor),
  - changing the approach with which the final `String` is produced,
    from asking the user to provide a bunch of some sort of template
    `String`, to asking them for a function that produces a `String`
    given the required inputs (e.g. the number of available updates).

0 files changed, 0 insertions, 0 deletions