Hi, firstly, love the plugin - great work!

I'm currently also using fidget.nvim and I've noticed that this plugin sends a lot of notifications and wondering if there's any way to quieten them? Can't see anything from the docs on this

Currently, info disappears when using folding from https://github.com/kevinhwang91/nvim-ufo. Any ideas on how we can prevent this?

(thanks for the plugin, simple and very useful!)

If it's possible to add a dividing line along with the text

like:

Hello

I've encountered a potential resource management issue in lsp-lens.nvim that seems to occur during rename operations in large files.

Issue Description

In a Django project, specifically while working with a views.py file approximately 900 lines long, I used both lsp rename and %s to rename variables and strings (related to modifying column names in queries). Post these operations, including after undoing the changes, the file descriptor count (lsof -p nvim_pid | wc -l) drastically increased and did not decrease, reaching up to 1069. This led to the following error, rendering many plugins nearly dysfunctional:

Error detected while processing InsertLeave Autocommands for "*":
Error executing lua callback: Vim:E903: Process failed to start: too many open files: "/usr/bin/zsh"
stack traceback:

Steps to Reproduce

Open a large Python file (like view.py in a Django project) with lsp-lens.nvim enabled.

Perform rename operations using lsp.buf.rename() or %s/string_a/string_b/g.
Observe the file descriptor count increase, with subsequent errors.
Environment
Neovim version:
NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1692716794

Operating System: Ubuntu 20.04.6 LTS on Windows 10 x86_64
This issue appears to be a file descriptor leak, particularly noticeable in large files during and after rename operations. It seems resources aren't being released properly after these operations.

I would appreciate any assistance or insights you can provide to help resolve this issue. Thank you for your contributions to this plugin.

Lastly, I want to express my appreciation for the creation of this interesting and useful plugin. It has been an invaluable tool in my development workflow. Thank you for your hard work and dedication to the Neovim community.

Best regards

For inline functions, it would be great to have options to configure it:

Just a suggestion, maybe an extra arguments for sections (lsp or treesitter object mabye), something like:

require'lsp-lens'.setup({
  sections = {
    definition = function(count, functionObj)
        ...
    end,
    references = function(count, functionObj)
        ...
    end,
    implements = function(count, functionObj)
        ...
    end,
    git_authors = function(latest_author, count, functionObj)
        ...
    end,
  }
})

#5 introduced change from implementation to implements while keeping readme outdated

fixed in #21

Hi! Thank you for creating nice plugin! I love your project.

Problem

As the title says, lsp-lens.nvim does not display anything when there is a declaration on the first line.

When I add comment above the declaration, References and Implements is shown.

Here is the code I used to reproduce it.

What I expect

I would like to see References and Implements displayed even if there is a declaration on the first line.

I would be very happy if you could consider this when you have time.

Hi,

I don't see any lenses when I turn this on.
Maybe the reason is because the LSP doesn't offer any lenses, how do I confirm if the LSP is offering lenses or not?
I tried this:

:lua print(vim.inspect(vim.lsp.codelens.get()))

and it results in {} which seems like no lenses are available, but IDK if I am doing something wrong

I have the following Lua code:

local function get_commands(filename_prefix)
  return M.split_string(M.read_file(string.format("%s.commands", filename_prefix)), "\n")
end

and I noticed that there is a weird indentation which I perceive to be due to local:

For anything without local it works just fine:

I think this might be a me issue but I'm confused why lsp-lens disables syntax highlighting when active when it finds a reference for a function or anything else.

Here is an example.

and here is an example where there are no references

Am I missing anything here?

xxxxManager is a struct and it implements Manager interface.
so lsp-lens should display Implements:1 | References: 5

Would be nice to make textDocument/definition configurable as it's not something I find particularly useful

If a language server doesn't support functionality required by lps-lens.nvim many errors are emitted:

method textDocument/references is not supported by any of the servers registered for the current buffer

repeatedly.

I see that this function exists:

local function lsp_support_method(buf, method)
  for _, client in pairs(lsp.get_active_clients({ bufnr = buf })) do
    if client.supports_method(method) then
      return true
    end
  end
  return false
end

But isn't called for every client request. This will fix it:

diff --git lua/lsp-lens/lens-util.lua lua/lsp-lens/lens-util.lua
index 7814e21..ea6ae8e 100644
--- lua/lsp-lens/lens-util.lua
+++ lua/lsp-lens/lens-util.lua
@@ -173,7 +173,7 @@ local function do_request(symbols)
       finished[idx][1] = true
     end
 
-    if config.config.sections.definition == true then
+    if config.config.sections.definition == true and lsp_support_method(vim.api.nvim_get_current_buf(), methods[2]) then
       lsp.buf_request_all(symbols.bufnr, methods[2], params, function(definition)
         counting["definition"] = result_count(definition)
         finished[idx][2] = true
@@ -182,7 +182,7 @@ local function do_request(symbols)
       finished[idx][2] = true
     end
 
-    if config.config.sections.references == true then
+    if config.config.sections.references == true and lsp_support_method(vim.api.nvim_get_current_buf(), methods[3]) then
       params.context = { includeDeclaration = config.config.include_declaration }
       lsp.buf_request_all(symbols.bufnr, methods[3], params, function(reference)
         counting["reference"] = result_count(reference)

2023-03-12T17:46:43 Error  ERROR Error executing vim.schedule lua callback: ...e/lazynvim/lazy/lsp-lens.nvim/lua/lsp-lens/lens-util.lua:140: handle 0x561bd1b0b760 is already closing
stack traceback:
	[C]: in function 'close'
	...e/lazynvim/lazy/lsp-lens.nvim/lua/lsp-lens/lens-util.lua:140: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

Haven't figured out the causing event yet

Hi,

In Go, it shows space before interfaces definitions:

As the screenshot shows, functions and methods display correctly, but only the interface has spaces.

Cheers,
Mort

I am getting this error when closing a tab quickly

Error executing vim.schedule lua callback: ...share/nvim/lazy/lsp-lens.nvim/lua/lsp-lens/lens-util.lua:174: handle 0x5632b6469090 is already closing
stack traceback:
        [C]: in function 'close'
        ...share/nvim/lazy/lsp-lens.nvim/lua/lsp-lens/lens-util.lua:174: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

This seems to be cased by something that runs asynchronously and attempts to close something already closed (just a hunch)

Would be nice to have, since i'm planning to mimic the IntelliJ one as close as possible

Thank you for the great plugin, it is awesome!

What do you think about allowing the users to trigger the plugin only when in the current function scope, rather than showing all the references for all functions in a buffer? I find that having a code lens with references is fantastic, however it may sometimes clutter the screen (and slow down scrolling and movements, probably due to extensive treesitter parsing); as such, a great quality-of-life improvement would be to only show the code lens for the function my cursor is in.

Likewise, a similar option could be to trigger to toggle the lens on CursorHold and then re-toggle it off automatically when the cursor moves (or similar mechanics).

In Python, the number of References always includes the definition of, e.g., the method, even when include_declaration = false in config . I am not sure if this is intended or not, but I would prefer the number of usages .

I'm testing the plugin with a C source code with clangd enabled.

Nohing changes when LspLensOn is executed.

My Lazy config:

{
  'VidocqH/lsp-lens.nvim',
  config = function()
    require'lsp-lens'.setup({
      enable = true,
      include_declaration = false,      -- Reference include declaration
      sections = {                      -- Enable / Disable specific request
        definition = false,
        references = true,
        implements = true,
      },
      ignore_filetype = {
        -- "prisma",
      },
    })
  end,
  enabled = lvim.builtin.lsp_lens.active,
}

clangd LSP is working as expected, though.

Also I tried with other filetypes, nothing happens.

Neovim version: v0.9.2

How to reproduce:

1. find a Lua function defined with a module, e.g.: function lsplens:lsp_lens_toggle()
2. check the references count

should lsp_lens_toggle references count not be lsplens references count

Introduction

VSCode's codelens functionalities are extensive, and users who want to mimic parts of them cannot because sections are restricted to certain defaults. Allowing the user to define custom sections would be useful for achieving pieces of information that lsp-lens should not have to maintain.

Example

For example, I personally would like to implement something like in the below image, where the user can see how many tests for the current function/method exist and how many are passing. Tools like Neotest may be able to provide the information (if it has an API), but I'd like to display it in the codelens format instead of in the sign or diagnostic columns.

Image Source

Idea

Much like statuscol.nvim, lsp-lens.nvim could use a table of sections with some defaults that are built-in, such as "references", "definitions", and so on (it already does this 👍🏻). It could also allow the user to define custom sections that will be evaluated and return a string.

If this is interesting, I'd be interested in working on it. Maybe lsp-lens could expand to more than just LSP, like you are doing with the git author provider you mentioned here.