feat(ui): add show_modified option

[sstallion]

This PR adds a new configuration option to control when the modified icon is rendered. Possible values for this option are a boolean, a predefined set of strings ("active" and "inactive"), and function(context): boolean if further customization is required.

The impetus behind this change is largely selfish; in my current setup I already have a modified indicator on the statusline, which makes the bufferline icon superfluous. By setting options.show_modified = function(context): boolean, I can now see which tabs have been modified without adding duplicate information to the UI.

[sstallion]

EDIT: I've simplified changes a bit. I've dropped support for strings since I'm betting this isn't a feature that many will be using and it collapses naturally into using a function instead.

For reference, here is what I am using in my init.lua:

require("bufferline").setup {
  options = {
    show_modified = function(context)
      -- show modified icon for inactive tabs:
      return not context.tab:current()
    end
  }
}

[akinsho]

Hi @sstallion so actually I should probably document this in a contributing document somewhere but my main priority for this plugin right now is to reduce the complexity of the ever growing series of options, currently this plugin has dozens of options and one of the most complicated modules is the config module that is jumping through some very gnarly hoops to keep this under control.

My main regret regarding this plugin's development was that I wasn't stricter with what was customisable i.e. standing my ground when users asked for specific customisation options for their uses cases which is where the vast majority of these options come from rather than my preference.

Can this issue be solved by just setting the modified icon to an empty string, this week alone 3 new options have been proposed and I really don't want to add any new ones tbh. In the medium to longterm my plan is to expose the parts of a component so an advanced user can put them together how they want but I haven't settled on the API for that plus I really need to focus my time away from nvim plugins and onto other things so havent had the time.

Ideally eventually users can do something like

component = function(parts, element)
	return {
		parts.number,
		parts.modified,
		parts.name,
		vim.bo[element.id].some_option and parts.diagnostics or nil,
	}
end

This way hopefully I can remove all requests for I'd like to hide x or y and can just point people to the docs on how to structure whatever they want on their own without more complexity here.

[sstallion]

Hey @akinsho, thanks for the thoughtful response! I completely understand. Migrating 20+ years of vimrc hacking to nvim hasn't been the most entertaining thing to do, but it has been a good opportunity to think about how I can improve my workflow.

Can this issue be solved by just setting the modified icon to an empty string, this week alone 3 new options have been proposed and I really don't want to add any new ones tbh. In the medium to longterm my plan is to expose the parts of a component so an advanced user can put them together how they want but I haven't settled on the API for that plus I really need to focus my time away from nvim plugins and onto other things so havent had the time.

That was my first approach. One of the problems I ran into with modified_icon = "" was while the icon would be removed, so would the close icon when a buffer is modified. I'm not sure if this was intended or if it's just an artifact of using mode = "tabs", but it did get me thinking about how I would like to see modifications in general. These changes seemed like the simplest thing I could do to fix the above problem as well as provide a little bit of customization for those that might want to do something other than turn them on or off.

Ideally eventually users can do something like

component = function(parts, element)
	return {
		parts.number,
		parts.modified,
		parts.name,
		vim.bo[element.id].some_option and parts.diagnostics or nil,
	}
end

I really like this approach! I'm caught between a couple of projects at the moment myself, so I definitely understand time pressure.

As far as this PR goes, I'd certainly like to see it merged if it passes muster, but I understand wanting to avoid additional creep. I suppose worst case I could just maintain a fork until you have the bandwidth to overhaul customizing components.

Thanks again for a great plugin and let me know how you'd like to proceed!

[akinsho]

@sstallion setting the value to an empty string is expected to work so I guess that's a bug then so would definitely accept a fix for that. Alternatively have tried just setting the value to an empty string. The plugin shouldn't differentiate between an empty string and the modified icon so that should work

[sstallion]

@sstallion setting the value to an empty string is expected to work so I guess that's a bug then so would definitely accept a fix for that.

That was the behavior I saw originally - if modified_icon = "", then the close icon will disappear once a buffer is modified.

[akinsho]

@sstallion sorry I used empty string twice but what I meant to suggest was just using an empty space e.g. " " rather than ""

[sstallion]

@sstallion sorry I used empty string twice but what I meant to suggest was just using an empty space e.g. " " rather than ""

No worries! " " gives the same results as "". FWIW, this PR would fix that issue as well, albeit at the cost of one more configuration option. 😁