rebelot/heirline.nvim

Improvement: Ship a collection of default components

Closed this issue ยท 6 comments

Zeioth commented

Many distros implement their own collection of heirline components. For what I've observed, most of them are distro interdependent and re-implementing them could be avoided. For example:

  • Filename component to display the filename.
  • Nav component to display the % scrolled.
  • Git branch component to display the current git branch.

Shipping a default colection of components with heirline would take a good 2000+ lines of code out of distros using heirline.

Distros wanting to implement their own custom compenents could still do it.

I've observed this while working on NormalNvim, which inherits most of its heirline components from its parent distro AstroNvim. Probably most distros re-use components, as creating them from scratch can be very time consuming.

Another posibility could be creating a repository of premade heirline components.

I've been thinking about this, but I have some concerns as it requires a lot of arbitrary assumptions about users taste. Allowing "easy" customisation of default components would also introduce some higher-level API with arbitrary fields (i.e. separators, conditional highlighting, etc).

Maybe wiki with user submitted solutions would be enough to satisfy that itch while not putting any additional maintenance cost on you?

kyoh86 commented

If we want a "default" settings, we can use other status-line plugins that already provides such a thing.

I think that the value of this plugin is that it enables status lines to be represented by a group of components.
This allows users to easily configure the status line of their choice.
The "default" settings are for users who do not like to configure, such as using various distros.
Therefore, it is natural for each distro to implement it.
Plug-ins are not developed just for distros.

Providing default settings should be carefully placed on the plugin because it shifts the burden of dissatisfaction with "default" to the plugin author.
It is an action that increases the burden on them.

I agree with the idea that a wiki of sorts where users can easily show examples of settings would be sufficient. Or even like one community on reddit would be sufficient.

Zeioth commented

I still vote for at least having a wiki where people contribute with their component libraries.

In the same way most plugins that are actually engines (luasnip, dap, neotest...) do It.

Wiki is already there and some users already contributed :)