feat!: 0.7 API update

[mjlbach]

• switch to lua api for autocommands

• switch to nvim_create_user_command

• move to lua plugin initialization

• rename commands -> user commands to match API and free up commands
  namespace

  This will require users to update commands -> user_commands in the
  setup {} call.

[zappolowski]

I think, you've missed some spots which still reference the old .commands field. Using these changes, I at least got the basic functionality with user defined commands to work (default commands were working OOTB).

I'm still trying to understand how e.g. ranges are passed in Lua.

[mjlbach]

I'm still trying to understand how e.g. ranges are passed in Lua.

The lua callback receives a table as a single arg, it should be args.range

[zappolowski]

I'm still trying to understand how e.g. ranges are passed in Lua.

The lua callback receives a table as a single arg, it should be args.range

Thanks, I've figured out the issue I've had before: opts for nvim_create_user_command cannot be defined by the user, but needs to be { range = true } then.

diff --git a/lua/lspconfig/configs.lua b/lua/lspconfig/configs.lua
index 245e32f..867754e 100644
--- a/lua/lspconfig/configs.lua
+++ b/lua/lspconfig/configs.lua
@@ -277,7 +277,7 @@ function configs.__newindex(t, config_name, config_def)
       M.user_commands = vim.tbl_deep_extend('force', M.user_commands, client.config.user_commands)
     end
     for _, command_info in pairs(M.user_commands or {}) do
-      vim.api.nvim_create_user_command(command_info.name, command_info.command, { desc = command_info.description })
+      vim.api.nvim_create_user_command(command_info.name, command_info.command, vim.tbl_extend('keep', command_info.opts or {}, { desc = command_info.description }))
       M.commands_created = true
     end
   end

[mjlbach]

Ok, I think we should be good now? If you want tot take another look. I made the defined user_commands match the exact function signature of create_user_command

[zappolowski]

Just these two typos ... besides that, it works (for my use case) 👍

[mjlbach]

Whoops, bad force push, try now.

[zappolowski]

Thanks for your efforts. 👍

[mjlbach]

Thanks for catching my typos!

I'm going to give this a week to stew/people to read my warning message about breaking 0.6 compatibility before merging. Do you prefer the new interface for user_commands? I think it's more intuitive since the list maps directly onto the arguments passed to nvim_create_user_command now. Alternatively I could lift the name so that the table of user_commands is keyed by the command name instead of being a list, but IMO having the table include the exact arguments is cleaner. WDYT?

[zappolowski]

I also prefer to have the API resemble nvim_create_user_command as close as possible (less cognitive load in total).

While playing around with both approaches I ran into an issue. Using the list like form of tables means, that vim.tbl_deep_extend as used here cannot be used anymore (it's intended for map-like tables). The attempted merge results in vanishing default defined commands when user defined commands are used as well.

[mjlbach]

That's a good point, we can either key the table with the name of the command as before, or merge the lists manually without extending the original table

[zappolowski]

Personally, I would stick to the new API with lists (as written before) and thus just merge the lists.

One thing (and that's actually how I found the issue) to consider then, is how to handle both intentional (e.g. when one wants to alter an existing command without having to come up with a new name) and unintentional (implementing a command which is then later provided by this plugin) overwriting of existing commands.

My proposal would be to use the default defined commands as the base list and add user defined commands in the end. This way both sets of commands should still work and intentional overwriting will work as well. I would guess that unintentional overwriting is rare enough to be dealt later.

[mjlbach]

We might even just do away with the user_command entrypoint to setup{}... there's no reason that a user can't just use on_init or on_attach to map the command themselves now that we have the lua api, before there was a motivation for the sugar as it took care of the annoyance of the vimscript api.

[mjlbach]

I decided to just have user_commands overwrite then trying to merge so users can disable the default command mappings, also I think if people really want to map their own commands they can just call the create_user_commands api directly. Still need to fix docgen and then this is g2g

[ranjithshegde]

Is anyone working on this since the departure of our beloved maintainer mjlbach?
I have been riding this branch since its creation and its been working great!
Willing to help out with tests or any other way necessary

[mjlbach]

I'm still alive fwiw :) I just wanted to set clear expectations on my response time/responsibilities (indefinite, and none) while I am on break.

The main reason I didn't merge this yet is because I was giving time for 0.7 to become the new standard. I know there is going to be some blowback dropping pre 0.7 support, but I wanted to do these cleanups for awhile.

[justinmk]

#1984