Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: remove the config.commands #2092

Merged
merged 4 commits into from
Aug 26, 2022
Merged

fix: remove the config.commands #2092

merged 4 commits into from
Aug 26, 2022

Conversation

glepnir
Copy link
Member

@glepnir glepnir commented Aug 26, 2022

now we can use vim.api.nvim_create_user_command in on_attach field to create commands just work for this server. so
there is no need this field config.commands .

Example:

  local function organize_imports()
    local params = {
      command = 'pyright.organizeimports',
      arguments = { vim.uri_from_bufnr(0) },
    }
    vim.lsp.buf.execute_command(params)
  end

  local on_attach = function(client, bufnr)
    if client.name == "pyright" then
      vim.api.nvim_create_user_command("PyrightOrganizeImports", organize_imports, {desc = 'Organize Imports'})
    end
  end

  require("lspconfig")['pyright'].setup({
    on_attach = on_attach
  })

Fix #1750


Warning: Commands is deprecated and will be removed in future releases.
It is recommended to use `vim.api.nvim_create_user_command()` instead in an `on_attach` function.
Custom commands only work for servers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Custom commands only work for servers
Custom commands only works for servers

I think that entire section about custom commands is not needed anymore?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it can help some people so keep it . like some new vimer this can give them a tip

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt new people are going to define custom commands. This is an advanced thing to do, and for that they should refer to neovim LSP documentation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it. remove

for command_name, def in pairs(commands) do
local opts = M._parse_user_command_options(def)
local _, opts = unpack(def)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
local _, opts = unpack(def)
local opts = def[2]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

return opts
end

---@deprecated
function M.create_module_commands(module_name, commands)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, this function was only used in configs.lua and was not documented. Can't we just get rid of it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup. But I'm not sure if this function is used by anyone else. Because he is derived. so i didn't remove it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a quick search on github, and seems like there are only lspconfig forks. I think it's okay to get rid of it entirely

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done .

@glepnir glepnir merged commit 99e0dc9 into neovim:master Aug 26, 2022
@ranjithshegde
Copy link
Contributor

ranjithshegde commented Aug 26, 2022

now we can use vim.api.nvim_create_user_command in on_attach field to create commands just work for this server. so there is no need this field config.commands .

Example:

  local function organize_imports()
    local params = {
      command = 'pyright.organizeimports',
      arguments = { vim.uri_from_bufnr(0) },
    }
    vim.lsp.buf.execute_command(params)
  end

  local on_attach = function(client, bufnr)
    if client.name == "pyright" then
      vim.api.nvim_create_user_command("PyrightOrganizeImports", organize_imports, {desc = 'Organize Imports'})
    end
  end

  require("lspconfig")['pyright'].setup({
    on_attach = on_attach
  })

Fix #1750

I am a bit too late for this. But this breaks all the internal commands like texlab-build.
The above example only works if the client provides workspace/executeCommands that dont require params field.
In the case of clangdSwitchSourceheader and all texlab commands, you need to write this manually like this

local texlab_build_status = vim.tbl_add_reverse_lookup {
  Success = 0,
  Error = 1,
  Failure = 2,
  Cancelled = 3,
}

local texlab_forward_status = vim.tbl_add_reverse_lookup {
  Success = 0,
  Error = 1,
  Failure = 2,
  Unconfigured = 3,
}

local function buf_build(bufnr)
  bufnr = util.validate_bufnr(bufnr)
  local texlab_client = util.get_active_client_by_name(bufnr, 'texlab')
  local params = {
    textDocument = { uri = vim.uri_from_bufnr(bufnr) },
  }
  if texlab_client then
    texlab_client.request('textDocument/build', params, function(err, result)
      if err then
        error(tostring(err))
      end
      print('Build ' .. texlab_build_status[result.status])
    end, bufnr)
  else
    print 'method textDocument/build is not supported by any servers active on the current buffer'
  end
end


--- and only then 
vim.api.nvim_create_autocmd(--[[stuff]])

And with configs.command removed, none of the internals defined in lspconfig/server_configurations/[sever].lua work anymore

@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

it should be rewrite I think follow this in doc. notice lspconfig only provide the basic lsp server settting .

Warning: Commands is deprecated and will be removed in future releases.
It is recommended to use `vim.api.nvim_create_user_command()` instead in an `on_attach` function.

@ranjithshegde
Copy link
Contributor

ranjithshegde commented Aug 26, 2022

it should be rewrite I think follow this in doc. notice lspconfig only provide the basic lsp server settting .

Warning: Commands is deprecated and will be removed in future releases.
It is recommended to use `vim.api.nvim_create_user_command()` instead in an `on_attach` function.

Yes but the plan was to soft deprecate it over future releases. At least thats what was discussed during #1984

I added that messaage in lspconfig.txt and it was only merged 3 days ago. too little warning. Should it not be at least a release cycle?

And as far as I can tell, there are no plugins out there that do this for texlab. This breaks config of anyone who uses texlab.
This breaks it with no alternatives for users to use.
The only people who were aware of this removal were people who participated in PR review

@ii14
Copy link
Member

ii14 commented Aug 26, 2022

Oh, server configurations were not migrated before this? Sorry, I should've checked that. I think this has to be reverted for now then

@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

future releases so future is what time. now we have api can do this. I don't understand why this field was buggy in the past. So do you think there are any commands available. Because of this field, there are constantly some prs that are deeply bound to the server config. It's weird. And justin has removed part of it. I think should be provide a new api like a function to do that. not use this commands field

@ranjithshegde
Copy link
Contributor

future releases so future is what time. now we have api can do this. I don't understand why this field was buggy in the past. So do you think there are any commands available. Because of this field, there are constantly some prs that are deeply bound to the server. It's weird. And jusmtin has removed part of it. I think should be provide a new api like a function to do that. not use this commands field

The plan discussed with justin was that we soft deprecate it, and no longer allow users to define it in their config, but keep the internals that are part of server_configurations/[server].lua

Also 3 days is by no means a sufficient warning to remove something with 0 alternattives

@ii14
Copy link
Member

ii14 commented Aug 26, 2022

But it's still used in default configurations. I don't think we can just set a default on_attach, because it can get overridden by the user, right? So it's not a trivial change.

@ranjithshegde
Copy link
Contributor

But it's still used in default configurations. I don't think we can just set a default on_attach, because it can get overridden by the user, right?

With this PR, the commands as part of default configuration no longer work

@ii14
Copy link
Member

ii14 commented Aug 26, 2022

Yes, this is exactly what I mean.

@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

maybe the design of this field commands was a mistake from the start. Deep bundling brings new PRs and issues

glepnir added a commit that referenced this pull request Aug 26, 2022
@ranjithshegde
Copy link
Contributor

maybe the design of this field commands was a mistake from the start. Deep bundling brings new PRs and issues

I fully agree, 100%. But as it stands, this is part of so many (at least 8 that I know of) LSPs, and most users are accustomed to having it. It needs a bit of slow deprecation.

@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

need redesign and provide a new api to do .then they can implement what they want in local not in this project.

@ranjithshegde
Copy link
Contributor

ranjithshegde commented Aug 26, 2022

need redesign and provide a new api to do .then they can implement what they want in local not in this project.

This has to be done. But is not trivial. Some servers like pyright just need workspace/executeCommand and then its simple. Others like texlab require textDocument/myFancyOffspecCmd which need params and ctx handling.
Cant make a generalized function.

For some servers there are dedicated plugin. zk has one, clangd has one, I wrote one a few days ago for ccls. So just pointing to dedicated plugins wont work for many other servers

@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

Some issues need to be looked at carefully. what do they need. Provide a function or something to bring some of the information they need.

glepnir added a commit that referenced this pull request Aug 26, 2022
@glepnir
Copy link
Member Author

glepnir commented Aug 26, 2022

revert. I think there is a bug in commands so no one uses it. Then I remove something. Sorry for the inconvenience

@ranjithshegde
Copy link
Contributor

revert. I think there is a bug in commands so no one uses it. Then I remove something. Sorry for the inconvenience

Removal is the correct and long term idea. Maybe after 0.14 we remove this from userspace and only keep the existing defaults in server_configurations/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How to set per-client commands to start_client?
3 participants