v2.0.0 Tracking Issue

[Iron-E]

In #386, there was discussion of breaking compatibility with ^1.0.0 by removing support for g:bufferline. This issue is to track what changes we are looking to make for a potential v2 release.

• [x] Remove plugin/barbar.lua to enable lazy-loading
  • #438
• [x] Remove g:bufferline. We can use dictwatchers to deprecate it
  • #396
  • #399
• [x] Remove functionality annotated with utils.deprecate (e.g. state.set_offset, the icon_close_tab option).
• [ ] Changes to setup. We don't actually have to do this, but it's worth considering:
  • exclude_name, exclude_ft → hide = {name = {}, ft = {}}
  • highlight_alternate, highlight_inactive_file_icons, highlight_visible → highlight = {alternate = …, inactive_file_icons = …, visible = …}
  • insert_at_start, insert_at_end → insert_at = 'left'|'right'|'start'|'end'
  • maximum_padding, minimum_padding → padding = {maximum = …, minimum = …}
  • maximum_length, no_name_title → filename = {maximum_length = …, default = …}
• [ ] Deprecate the autoload functions? e.g. bufferline#render
• [ ] Should we raise the minimum Neovim version to 0.8? That would also let us remove more VimScript
• [ ] Stop supporting require('bufferline'): #535

[otavioschwanck]

i like the changes on setup, i think is worth

[romgrk]

I think we should aim to have a gradual non-breaking migration, until the last step of the process.

1..setup() would accept the exact same format as g:bufferline, we update the doc to use .setup() as the only documented method, but g:bufferline keeps working as before 2. we add a one-time notification when neovim opens announcing the change in format, with a clear migration path 3. we remove support, but show an error notification if g:bufferline is present telling users to .setup(vim.g.bufferline) please 4. remove support & notification

We should also mark our commit as breaking with the conventional commits notation (feat!: ...), I've seen some package managers display breaking notices when they detect those when the user upgrades their plugins.

[romgrk]

I'm cool with the bufferline => barbar rename as well, but let's try to migrate gradually as well.

[Iron-E]

Thanks for the feedback. I'll keep this issue updated the transition can be monitlred item-by-item at a glance

[ttytm]

+1 on the neovim version upper from my side. 0.9 is coming up and supporting for the last two "stable" versions of an early project is fair enough.

Would adding a formatting standard / config that can be automated be something for that version release?

Could be stylua, lua_ls or .editorconfig. Adding any of these would introduce formatting changes. So why not now? Shouldn't be a lot of work either, adding the desired config and running one command on the full project should probably be it.

edit: Just saw there is #411