neovim / neovim

Vim-fork focused on extensibility and usability
https://neovim.io
Other
83.1k stars 5.69k forks source link

The culling of vim.lsp.util #25272

Open gpanders opened 1 year ago

gpanders commented 1 year ago

Problem

vim.lsp.util is a dumpster that needs to be cleaned up. This process has already been started in #25073. But the pruning must continue.

This is a tracking issue for substantially reducing the size and scope of vim.lsp.util. Ideally, it will be removed completely (deprecated first, of course, and removed in a future release).

In particular, new homes should be found for:

The list above is non-exhaustive, it may be updated with new items as the effort progresses.

MariaSolOs commented 1 year ago

try_trim_markdown_code_blocks also feels like an utility function that we should get rid of.

mfussenegger commented 1 year ago

_get_completion_item_kind_name This is a one line function. Why is this needed? Can it be inlined/deleted? @mfussenegger

Looks like it was due to testing: https://github.com/neovim/neovim/commit/9a67b030d9a054648296b45b615684dee768582d But inlining sounds good to me - or a candidate for ⬇️

text_document_completion_list_to_complete_items The name alone suggests this is a special purpose function and doesn't belong in "util". Is there a more appropriate location?

There is some discussion around introducing a lsp.completion module. My preference would be to then make it private within that module. See https://github.com/neovim/neovim/pull/24661#issuecomment-1691150950

_str_utfindex_enc and _str_byteindex_enc These are advertised as "convenience wrappers" around vim.str_utfindex and vim.str_byteindex, respectively. Consider > updating those functions to accept an encoding instead.

Another potential alternative would be to mix this into some kind of position or range abstraction. I have some vague idea about that, but won't be able to try it anytime soon.

+1 for all the others.

justinmk commented 1 year ago

_normalize_markdown should be made public, but not under vim.lsp.util. TBD on the correct namespace

Another potential alternative would be to mix this into some kind of position or range abstraction.

Reference: https://github.com/neovim/neovim/issues/25509

💯 for the other suggestions in this issue, with these comments:

clason commented 1 year ago

Counterpoint: normalize_markdown is markdown specific

But it renders markdown as text, so vim.text would arguably fit.

(I'm wary of opening the floodgates for shoving functionality into vim.filetype.<ft> sub-submodules.

👍 for Taking vim.region Seriously.

gpanders commented 1 year ago

Should the open_float features be owned by nvim_open_win instead of adding vim.ui.open_float ?

I've no objection, though having more of this done in Lua rather than in C might be nice.

Are both vim.ui.open_win + vim.ui.open_float needed, or could vim.ui.open_win ergonimically cover both (float and non-float) use-cases?

That seems reasonable to me.

gpanders commented 1 year ago

I created https://github.com/neovim/neovim/issues/25514 to track the vim.ui.open_win() (and related) design, specifically.

AlexXandreE commented 5 months ago

Sorry to reopen this but I see text_document_completion_list_to_complete_items is listed as deprecated and the reference to a lsp.completion module, but as it is, how can I get over the deprecation? It seems nothing replaces it atm.

mfussenegger commented 5 months ago

Sorry to reopen this but I see text_document_completion_list_to_complete_items is listed as deprecated and the reference to a lsp.completion module, but as it is, how can I get over the deprecation? It seems nothing replaces it atm.

There's no direct replacement and there won't be one. You'll either have to use the higher level API (omnifunc, enable, trigger) or re-implement the parts you need tailored to your requirements.