@justinmk when we chatted about this, you menteiond that we alredy have the concept of handlers. I think that's actually what I'm making here in actions.

If I replace actions with handlers, does it make more sense and seem within the right scope?

If I replace actions with handlers, does it make more sense and seem within the right scope?

Maybe. Will look at this now. I also see we have "hooks", at least internally, as implied by add_hook_before:

https://github.com/neovim/nvim-lspconfig/blob/4b440038709599f1c42712dda45aa8f2b6d591c0/lua/nvim_lsp/util.lua#L258

This is too many similar-but different concepts. It's unnecessary and puts the work of tying these concepts together on the user (or at least contributors) instead of doing that work in the API design.

So a user or plugin author has to internalize

1. autocmds/events
2. notifications (RPC)
3. "attach"
4. callbacks
5. hooks
6. handlers
7. and now maybe also "actions".

All with semantics that are accidentally different, not essentially different. Just because we didn't do the work of designing a better abstraction. It is easy/fast to add a new "inner platform", but painful for users/contributors, documentation, discussion, debugging, reasoning.

Yes, I agree with you.

I think callbacks, handlers and (my mentioned here) actions call all be the same item for what we're going for here. I'd suggest when lookin at this PR to probably just thinking of everything with the word actions to just be changed to handler. These should be able to be used as the callback for requests sent to LSP servers.

I do not know what hooks are for -- they don't appear in core as far as I know. I haven't done much in lsp configs in awhile.

I have a few goals tha I want to accomplish with a PR , some of the more long term. I suppose they don't have to live in core, but some of include:

1. Allow users to easily customize behavior for builtin callbacks
2. Provide library of functions to centralize interacting with LSP items (like jump_to_location, or highlight_location), since I think some of them could be useful for more purposes (and there are many difficult things, like handling multibyte situations, for example).
3. Not make users have to copy and paste code from core into their init.vim to change one line (for common cases) so that their experience doesn't become stale or regress over time.

But maybe it's too late in the day and I'm not making sense.

Perhaps one of the Location handlers might make more sense why I was going for this structure, which was why I started writing the code in this fashion before.

What I gathered from our (very productive!) discussion:

• M['textDocument/foo'] = vim.lsp.with(M['textDocument/foo'], { flag=bar }) seems like a good interface for lettings users override LSP handlers with configuration.
• Put LSP modules like diagnostics directly into vim.lsp.diagnostics. Don't need submodules of submodules (vim.lsp.foo.bar.diagnostics).
  • LSP's topics largely dictate our API surface area, little we can do about this (we did decide to implement an LSP client), except to avoid overthinking it.
• Don't need "actions" as a new concept, but it could make sense to put these handlers in callbacks.lua.
  • Naming convention: on_xx

Note to self: Update docs w/ new signature.

Note to self: lsp-callbacks should exist again by the time I'm done w/ the PR

add_hook_before is a generic utility function, it doesn't imply the existence of a concept of a hook outside of the singular case of adding a hook before the second parameter, aka chaining functions, but it's the old name I used to use for that utility. I also sometimes call it fn_then.

Error using the util endpoint for code_action AND range_code_action:

E5108: Error executing lua /usr/local/share/nvim/runtime/lua/vim/lsp/buf.lua:281: attempt to call field 'get_line_di
agnostics' (a nil value)

  context = context or { diagnostics = util.get_line_diagnostics() }

mapper(
'n',
'dn',
'lua vim.lsp.diagnostic.goto_next()'
)

mapper(
'n',
'dp',
'lua vim.lsp.diagnostic.goto_prev()'
)

Running :lua vim.lsp.diagnostic.set_loclist() on build 83e278ead returns E5108: Error executing lua runtime/lua/vim/lsp/diagnostic.lua:1032: attempt to index local 'opts' (a nil value).

I have underline enabled but it doesn't show up.
How will it be displayed?

My setting

vim.lsp.handlers["textDocument/publishDiagnostics"] = vim.lsp.with(
    vim.lsp.diagnostic.on_publish_diagnostics, {
        underline = true,
        virtual_text = true,
        signs = true,
        update_in_insert = true,
  }
)

you should config underline highlight group .

If you're having issues with this branch, please make an issue on neovim, follow the issue template and then tag me so I can take a look at it there. Thanks.

It's done. Thank you!

function! SetLSPHighlights()
    highlight LspDiagnosticsUnderlineError guifg=#EB4917 gui=undercurl
    highlight LspDiagnosticsUnderlineWarning guifg=#EBA217 gui=undercurl
    highlight LspDiagnosticsUnderlineInformation guifg=#17D6EB, gui=undercurl
    highlight LspDiagnosticsUnderlineHint guifg=#17EB7A gui=undercurl
endfunction

autocmd ColorScheme * call SetLSPHighlights()