New Overlapping Components Idea

[cseickel]

Background

So @lopi-py is adding the file nesting feature and that lead to a discussion on how to add a new component that needs to overlap with the indent component to look correct, especially with the indent guides turned on. (Issue: #118 PR: #164)

Here's an example:

In the screenshot above, the arrow/triangle icon to the left of the folders is replacing indent guides that would normally be there, instead of just pushing them to the left. The actually nesting part is at the bottom with the "test" files.

That got us thinking about finding a clean way to do this that does not involve just making the indent component responsible for this. The reasons against it is that it's obviously more correct to have each component do only one thing, and it doesn't seem intuitive to go to the indent component to configure the expanders used for the file nesting feature.

Solution

My solution to this problem is to create system where you can define overlapping components, where each subsequent component will just overwrite the one below it. This can be used in other situations as well, but for the indent/expander example, if we say that an array of components are overlapping components:

require("neo-tree").setup({
  renderers = {
    directory = {
      -- HERE IS THE OVERLAPPING COMPONENTS
      {
        {
         "indent",
          zindex = 10,
          indent_size = 2,
          padding = 1, -- extra padding on left hand side
        },
        {
          "indent_guide",
          zindex = 20,
          align = "right",
          enabled = true,
          indent_marker = "│",
          last_indent_marker = "└",
          highlight = "NeoTreeIndentMarker",
        },
        {
          "expander_icon",
          zindex = 30,
          align = "right",
          enabled = true, -- if nil and file nesting is enabled, will set to true
          expanded = "-", -- expanded icon
          collapsed = "+", -- collapsed icon
          highlight = "NeoTreeExpander",
        },
      },
      -- END OF EXAMPLE
      {
       "icon",
        folder_closed = "",
        folder_open = "",
        folder_empty = "ﰊ",
        default = "*",
      },
      {
        "name ",
        trailing_slash = false,
        use_git_status_colors = true,
      },
      {
        "git_status ",
        symbols = {
          -- ommitted for brevity
        }
      },
    },
    file = {
      -- pretty much the same as directory
    }
  },
})

When rendered, that first array of components will produce this for something three levels deep:

indent creates six spaces:                          |"      "|
indent_guide outputs a marker, right aligned:       |    "| "|
expander_icon outputs an expander, right aligned:   |    "> "|
---------------------------------------------------------------
which merges together, last one in wins, to:        |"    > "|

whereas if expander_icon were blank, it would be:   |"    | "|

The same strategy could be used to have multiple components for an icon where it can be overwritten in special situations.
Maybe some people want to replace a file icon with a diagnostic icon if there is an error.

It can also be used to right align something to the right edge of the window if we add a component that is a "flex" component that just fills with spaces up until the width of the window. That way we can take any component and put it in the right hand column, such as the git status like vs code does. We can also include the name component itself in an overlapping component, so that the git status and/or diagnostic signs are guaranteed to be shown on the right hand side even if a file name is too long to fit.

The technical solution on how to apply overlapping components is not too hard. The really hard part is how to present it in a way that it is intuitive for everyone to work with in a config table. The two obvious ideas to me are to either:

1. go with the example above where "overlapping components" are just an array and the first or largest one determines the overall size.
2. Create a new "container" component that contains the other components in a "children" array. Then the container can have properties to determine the size, like

• width = 4
• width = "100%"
• width = "size_to_content"
• width = function(node) return node.indent * 2 end.

[lopi-py]

I like the first idea, also I suggest something like

{
  "indent",
    zindex = 10,
    indent_size = 2,
    padding = 1, -- extra padding on left hand side,
    extensions = {
      { "indent_guide", enabled = true, zindex = 10, align = "right", ... }, -- `...` = the config itself
      { "collapser_icon", enabled = true, zindex = 20, align = "right", ... }, -- `...` = the config itself
    },
},
{
  "name",
  trailing_slash = false,
  extensions = {
    { "git_status", enabled = true, zindex = 10, align = "right", use_colors, symbols = { ... } },
  },
},

[cseickel]

In your third option above, there's not quite enough information to specify that the git_status ends up on the right most column of the window, because there's nothing to specify that the overall size of the "name" component should be exactly the remaining width of the window.

One way to take this idea and enable that ability would be to add a component that fills the remaining width, and add the "name" and "git_status" components as extensions:

{
  "indent",
    zindex = 10,
    indent_size = 2,
    padding = 1, -- extra padding on left hand side,
    extensions = {
      { "indent_guide", enabled = true, zindex = 10, align = "right", ... }, -- `...` = the config itself
      { "collapser_icon", enabled = true, zindex = 20, align = "right", ... }, -- `...` = the config itself
    },
},
{
  "stretch_container",
  extensions = {
    { "name", trailing_slash = false, zindex = 5 }
    { "git_status", enabled = true, zindex = 10, align = "right", use_colors, symbols = { ... } },
  },
},

So that leaves us with three choices:

1. Simple array, where the first component sets the size.
2. Explicit container components, with a width property and a children or contents array
3. Any component can become a container by adding an extensions array

Anyone else have any input? What do you think @bennypowers ?

[cseickel]

After looking through the options, I feel like having an explicit "container" component is the most obvious way of configuring this functionality. Here's what I'm thinking:

local config = {
  renderers = {
    {
      "container",
      width = "fit_content", --<-- default value for width
      content = {
        {
          "indent",
          zindex = 10,
          indent_size = 2,
          padding = 1, -- extra padding on left hand side,
        },
        { "indent_guide", enabled = true, zindex = 10, align = "right", ... }, -- `...` = the config itself
        { "collapser_icon", enabled = true, zindex = 20, align = "right", ... }, -- `...` = the config itself
      }
    }
  },
  {
    "container",
    width = 2,
    content = {
      { "icon", zindex = 10 },
      { "diagnostics", zindex = 20, show_errors_only = true },
    }
  },
  {
    "container",
    width = "100%", -- <-- means 100% of what's left from the current column to the window width
    content = {
      { "name", trailing_slash = false, zindex = 5 },
      { "git_status", enabled = true, zindex = 10, align = "right", symbols = { ... } },
    }
  }
}

Of course, at this point this is a bigger issue than can be handled within the file nesting PR and shouldn't hold that up or even be done there. I was originally hoping that the design of this could somehow fit into that but that was a bad idea...

[bennypowers]

can we get some config to show nested files even if they're hidden and hidden files aren't shown?

e.g. yes hide node_modules, but don't hide index.js.map, even though they're both gitignored.

[bennypowers]

we could also use a toggle_children next to toggle_directory in commands.lua

[cseickel]

can we get some config to show nested files even if they're hidden and hidden files aren't shown?

e.g. yes hide node_modules, but don't hide index.js.map, even though they're both gitignored.

Would that only be for specific named files, or for any file that is nested? Would this only apply to gitignored and never the hide_by_name nodes?

[cseickel]

I just realized this was added to an existing discussion and it should really be a new one. Let's move this to an issue.