feat(pack): added rainbow-delimiter.nvim integration for indent-blankline.nvim

[ammuench]

📑 Description

Adds a plugin to create a mock of the old VSCode bracket-pair-colorizer based on a custom config for indent-blankline and rainbow-delimiters plus some custom color mappings & vim mappings built by myself.

Creates a "dashed" colorized line for bracket/indent pairs within AstroNvim and highlights the corresponding bracket/XMLtag to make the scope clear.

Shows the active scope based on your treesitter language pack, can be disabled/toggled by user request. Mapping to toggle the indent highlighting in general also provided

ℹ Additional Information

Users can turn scope highlight off with command in README.md.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Proper usage of opts table rather than setting things up with the config function.

[Uzaaft]

Please go trough your PR again

[ammuench]

Please go trough your PR again

Apologies if I'm missing something obvious, but nothing seems to be off-spec from the contribution docs and comparing to other recent PRs?

The only thing I can see is my preview image potentially throwing the github actions parser an error possibly? I can remove that if so, but I thought it would be valuable for a primarily visual UI update based plugin.

Otherwise my PR title seems to be meeting standards (and is passing in CI). I don't mean to cause any additional work but I am a bit lost as to what needs fixing and would appreciate some guidance

[Uzaaft]

Please go trough your PR again

Apologies if I'm missing something obvious, but nothing seems to be off-spec from the contribution docs and comparing to other recent PRs?

The only thing I can see is my preview image potentially throwing the github actions parser an error possibly? I can remove that if so, but I thought it would be valuable for a primarily visual UI update based plugin.

Otherwise my PR title seems to be meeting standards (and is passing in CI). I don't mean to cause any additional work but I am a bit lost as to what needs fixing and would appreciate some guidance

You’ve got some unessecary files

[ammuench]

Please go trough your PR again

Apologies if I'm missing something obvious, but nothing seems to be off-spec from the contribution docs and comparing to other recent PRs?
The only thing I can see is my preview image potentially throwing the github actions parser an error possibly? I can remove that if so, but I thought it would be valuable for a primarily visual UI update based plugin.
Otherwise my PR title seems to be meeting standards (and is passing in CI). I don't mean to cause any additional work but I am a bit lost as to what needs fixing and would appreciate some guidance

You’ve got some unessecary files

Removed the accidental :q file I accidentally touched--let me know if there's anything else i'm missing!

[Uzaaft]

I'm not sure if this better fits a recipe.
@mehalter Any feedback re this?

[ammuench]

I'm not sure if this better fits a recipe. @mehalter Any feedback re this?

Happy to move it there if that makes more sense--put it with indent to match the NeovimCraft category per the contribution docs

[mehalter]

@ammuench Ok, I took a deep look at this today and have a recommendation on a different type of implementation for this that (1) greatly simplifies the implementation, (2) makes it much easier for the end user to further configure the plugins fully, (3) makes the end product a bit less distracting, and (4) adds full colorscheme support for any colorscheme that already supports rainbow-delimiters.nvim

Let me know what you think, I made sure this is in it's own commit so that it is quite easy to revert. This also lets us use the example image in the indent-blankline.nvim repo rather than including an entire image file in this repo which would be pulled on clones.

[mehalter]

Oh, also I think the location makes sense, I changed the wording a bit to match how we do the multiple copilot entries. Another approach would be to make it a "pack" since it configures multiple plugins but it makes it a bit harder to find imo. Or we could invert it to be rainbow-delimiters-indent-blankline and move it to the editing-support where the rainbow-delimiters.nvim entry is. I'm open to anything. The recipes/ folder is explicitly reserved for things in the AstroNvim documentation and recipes section.

[Uzaaft]

Oh, also I think the location makes sense, I changed the wording a bit to match how we do the multiple copilot entries. Another approach would be to make it a "pack" since it configures multiple plugins but it makes it a bit harder to find imo. Or we could invert it to be rainbow-delimiters-indent-blankline and move it to the editing-support where the rainbow-delimiters.nvim entry is. I'm open to anything. The recipes/ folder is explicitly reserved for things in the AstroNvim documentation and recipes section.

Then I think a pack makes more sense. Since it's multiple plugins being configured to work together

[mehalter]

Sounds good to me @Uzaaft ! Just updated the commit I made to move it to pack

[Uzaaft]

Plugin throws an error for me:

[mehalter]

@Uzaaft should be fixed now

[ammuench]

@ammuench Ok, I took a deep look at this today and have a recommendation on a different type of implementation for this that (1) greatly simplifies the implementation, (2) makes it much easier for the end user to further configure the plugins fully, (3) makes the end product a bit less distracting, and (4) adds full colorscheme support for any colorscheme that already supports rainbow-delimiters.nvim

Let me know what you think, I made sure this is in it's own commit so that it is quite easy to revert. This also lets us use the example image in the indent-blankline.nvim repo rather than including an entire image file in this repo which would be pulled on clones.

Thank you! Apologies for the delay, was tied up with work when I saw your updates. This implementation is actually something I was trying to figure out how to build--a config with a nice default that could be overwritten by the user--buy was struggling with implementation.

I may take a pass at updating the defaults to match the colorscheme I built, as they were intentionally set that way for usability, but I think this overall approach makes much more sense for extendability.

I can look into hosting the image from my fork as a remote URL if that would be preferred so that it doesn't need to live in this git repo history as well.

Thank you again for the feedback and update on my code!

[mehalter]

Yeah I think the main thing is trying to make the pack usable by the masses. So integrating it in a way that supports most colorschemes is much more sensible as a default than something that supports one colorscheme. And then something specific enough for your setup should go in your user configuration

[mehalter]

I can also help you migrate your code to the override code for this pack that you can include in your user configuration. It's very simple to achieve the final product you had originally from the current code I uploaded and overriding things in your user configuration

[ammuench]

Yeah I think the main thing is trying to make the pack usable by the masses. So integrating it in a way that supports most colorschemes is much more sensible as a default than something that supports one colorscheme. And then something specific enough for your setup should go in your user configuration

Happy to ultimately defer to this suggestion--but just to make my point--my goal was recreating this old VSCode addon where the bracket-pair and scope had different effects to highlight the scope you were focused in alongside your color-coded bracket pairs, which is why I built a separate theme and character type for the highlights vs the scope ibl line. If this is how ultimately how you'd prefer it to be, no worries, just explaining why my initial effort was so "opinionated"

Example:

[mehalter]

The shared image actually looks just like what the code I pushed does where the indentation lines are the normal dim and then the color matches the bracket pairs as such which I think looks great as a default:

[mehalter]

I did go ahead and add the show start and end back to my code to get that top line for example

[mehalter]

With the tighter integration with rainbow delimiters, to recreate your original code after you import this pack you can simply put this in your plugins/ folder:

return {
  {
    "HiPhish/rainbow-delimiters.nvim",
    opts = {
      highlight = {
        "RainbowRed",
        "RainbowYellow",
        "RainbowBlue",
        "RainbowOrange",
        "RainbowGreen",
        "RainbowViolet",
        "RainbowCyan",
      },
    },
  },
  {
    "lukas-reineke/indent-blankline.nvim",
    opts = {
      scope = { char = "▏", show_start = true, show_end = true },
      indent = {
        char = "╎",
        highlight = {
          "RainbowRedIndent",
          "RainbowYellowIndent",
          "RainbowBlueIndent",
          "RainbowOrangeIndent",
          "RainbowGreenIndent",
          "RainbowVioletIndent",
          "RainbowCyanIndent",
        },
      },
    },
  },
}

This assumes you have correctly set up the highlight groups, you can also extend AstroUI to more safely add in those highlight groups only if they don't exist in the colorscheme that is being loaded for example:

return {
  {
    "AstroNvim/astroui",
    ---@param opts AstroUIOpts
    opts = function(_, opts)
      if not opts.highlights then opts.highlights = {} end
      local init_highlights = opts.highlights.init or {}
      opts.highlights.init = function(colorscheme)
        if type(init_highlights) == "function" then init_highlights = init_highlights(colorscheme) end
        for hlgroup, fallback in pairs {
          RainbowRed = { fg = "#E06C75" },
          RainbowYellow = { fg = "#E5C07B" },
          RainbowBlue = { fg = "#61AFEF" },
          RainbowOrange = { fg = "#D19A66" },
          RainbowGreen = { fg = "#98C379" },
          RainbowViolet = { fg = "#C678DD" },
          RainbowCyan = { fg = "#56B6C2" },
          RainbowRedIndent = { fg = "#6e171e" },
          RainbowYellowIndent = { fg = "#765517" },
          RainbowBlueIndent = { fg = "#0c497a" },
          RainbowOrangeIndent = { fg = "#603d1d" },
          RainbowGreenIndent = { fg = "#3b5727" },
          RainbowVioletIndent = { fg = "#5a1b6d" },
          RainbowCyanIndent = { fg = "#1e4c52" },
        } do
          if vim.fn.hlexists(hlgroup) ~= 1 then init_highlights[hlgroup] = fallback end
        end
        return init_highlights
      end
    end,
  },
  {
    "HiPhish/rainbow-delimiters.nvim",
    opts = {
      highlight = {
        "RainbowRed",
        "RainbowYellow",
        "RainbowBlue",
        "RainbowOrange",
        "RainbowGreen",
        "RainbowViolet",
        "RainbowCyan",
      },
    },
  },
  {
    "lukas-reineke/indent-blankline.nvim",
    opts = {
      scope = { char = "▏", show_start = true, show_end = true },
      indent = {
        char = "╎",
        highlight = {
          "RainbowRedIndent",
          "RainbowYellowIndent",
          "RainbowBlueIndent",
          "RainbowOrangeIndent",
          "RainbowGreenIndent",
          "RainbowVioletIndent",
          "RainbowCyanIndent",
        },
      },
    },
  },
}

This would get you what you originally shared which had those extra dashed indent lines and uses your own custom highlight groups that wouldn't necessarily be supported by any other colorscheme:

[mehalter]

Let me know what you think @ammuench , my main point being I think the code that I pushed perfectly emulates the original Bracket Pair Colorizer 2 addon like you are looking for. Not sure if you tried it and didn't agree

[ammuench]

Let me know what you think @ammuench , my main point being I think the code that I pushed perfectly emulates the original Bracket Pair Colorizer 2 addon like you are looking for. Not sure if you tried it and didn't agree

This looks good to me! Appreciate the extra time with examples, it all finally clicked.

Stale

[mehalter]

Looks great! Thanks!