Allow coc list entries to be customized

[asmodeus812]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
There are sertain language servers, which do not only interact with physical files on the file system, but virtual buffers, such as kotlin, jdtls and others, it would be great if we are able to provide a format string for the symbols, to avoid having the following:

Notice that after the class type symbol name there is the jdt: link which however is very verbose, the goal here is to allow users to format this line, i for one would format it such that it strips away all the verbosity and only leaves the actual information i am interested in - which library it is coming from and the version of the library (with some regex manipulation this can be extracted). So for the first line it could look like that

# symbol coming from JDK 11, and is located in java.base/java.time
LocalDate [Class] [email protected]:java.time.LocalDate.class

My only concern is that this processing has to be done in the node client, and avoid doing it in vim/nvim to avoid locking the UI. But am not sure how it would be configured really. Could somehow specify a string representation of a function in coc-settings ?

I have already implemented something similar for my status line

          uriformats = {
            {
                "jdt://contents/([^/]*)/(.*)%?(.*)",
                function(comps)
                    local module  = comps[1]:gsub("%.jar", "")
                    local class   = comps[2]:gsub("/",     ".")
                    local version = comps[3]:match("jdk.*([^%%]%d+)%f[%D]")
                    if version and #version > 0 then
                        return string.format("%s@%s:%s", version, module, class)
                    end
                        return string.format("%s:%s", module, class)
                end,
            },
            {
                "term://(.*)//%d+:(.*)",
                function(comps)
                    return table.concat(comps, ":")
                end,
            },
            {
                ".*://(.*)"
            }, -- the default format
        },

Describe alternatives you've considered
There really is no actual alternative

Additional context
ibhagwan/fzf-lua#1575

[hexh250786313]

This might not be exactly what you're looking for, but since you mentioned list and fzf-lua, I wanted to share my approach: I use fzf-lua's custom picker functionality to replace some of coc's LSP-related list features. This allows me to customize the display content as needed. Here's how my symbol display looks:

For symbols, I prefer to show line and column information, and you can process the symbol information returned by the coc client as needed.

If you're interested, you can check out my configuration (note: comments are in Chinese, but you can use Google Translate): https://github.com/hexh250786313/dotfiles/blob/806e25cf858edf328c67f6ea93e546042e1051d2/.config/nvim/lua/modules/fzf/plugins/lsp.lua

Most of these configurations were learned from https://github.com/fannheyward/telescope-coc.nvim and fzf-lua's documentation. Hope this helps!

[asmodeus812]

@hexh250786313 thanks, i had considered this before creating this issue, what i do not like with this approach is that the entry processing is moved to the lua thread (with fzf-lua that could be done into a separate nvim instance, that might be enough, but i have to checkout the docs.), depending on the list sizes that could be quite impractical compared to doing the complete entry processing on the node client side and letting nvim only show it nothing else. Also on unreleated note, the coc-list interface is quite nice.

I have had the unpleasant experience with the native nvim lsp chuging hard locking the editor with quickfix list / lsp_references processing when the list numbers several thousand entries.

[asmodeus812]

Looking in the coc implementation the entries are actualy maybe even streamed in the coc list interface, meaning that the node client does not dump all entries to the nvim client to display them, they may be delievered in batches. So an lsp_references of 2k entries will not necessarily dump all of them at once into the nvim instance to get displayed - @fannheyward is that correct, are entries to get displayed batched or all entries from a response are sent at once ?