bug: The scopes view is showing the threads instead of the scopes sometimes

[NickJAllen]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

nvim -v NVIM v0.11.6 Build type: Release LuaJIT 2.1.1772619647

Operating system/version

MacOS or Linux

Describe the bug

When I am debugging lua plugin for Neovim the Scopes view just shows me the same contents as the Threads view.

This was working fine for me a few days ago but after recent updates I started to experience this

Steps To Reproduce

• Use https://github.com/jbyuki/one-small-step-for-vimkind to debug lua code from one Neovim instance to another
• Set a breakpoint and then try to show the scopes view
• Instead of showing the scopes it sometimes (nearly always for me) just shows the same contents as the Threads view

Expected Behavior

It shows the variables that are in scope instead of the thread stack trace

[igorlfs]

Hey,

Thanks for reporting. I've run into this issue myself. Not sure about the cause, though. My suspicion is that somehow nvim-dap is misbehaving on some "close session" event (not quite that, but akin).

This was working fine for me a few days ago but after recent updates I started to experience this

I find this to be unlikely. You can try bisecting.

---

I'll take a look

[HussainQadri]

I am also seeing the same visible symptom, although in my case I reproduced it with codelldb via nvim-dap while debugging C++/Rust. I think I have found one concrete cause of this behaviour.

On current main (e8199a2, feat: dim readOnly variables), switching to Scopes or Watches can fail after the winbar tab has already changed, leaving the previous Threads view content visible.

I hit this error when pressing W to switch to Watches:

E5108: Lua: .../lua/dap-view/options/winbar/init.lua:60:
.../lua/dap-view/util/hl.lua:54: attempt to concatenate local 'hl' (a nil value)

The crash happens in hl_from_variable():

local hl = v.type and M.types_to_hl_group[v.type:lower()]

if
    globals.HAS_0_12
    and v.presentationHint
    and vim.tbl_contains(v.presentationHint.attributes or {}, "readOnly")
then
    hl = hl .. "Dim"
end

If the adapter returns a variable or evaluate response with presentationHint.attributes = { "readOnly" }, but either no type or a type not present in types_to_hl_group, then hl is nil. The code then tries to concatenate nil with "Dim", which raises an error and aborts the view render.

switch_to_view() refreshes the winbar before calling the view's show() function so the selected tab changes but the previous view contents remain visible. That can make it look like Scopes is showing Threads. This behaviour also happens to me with the Watches tab.

This local patch fixed that crash for me. It adds a guard for this case: only append "Dim" if a valid highlight group was already found.

if
    globals.HAS_0_12
+   and hl
    and v.presentationHint
    and vim.tbl_contains(v.presentationHint.attributes or {}, "readOnly")
then
    hl = hl .. "Dim"
end

I verified locally that:

• an unknown read-only variable now returns nil highlight instead of crashing
• a known read-only type such as int still returns NumberDim

Opened a small PR for the guard here: #182

[igorlfs]

I am also seeing the same visible symptom

Your issue was actually unrelated. This issue predates the dimming of readOnly variables.

[HussainQadri]

Thanks for clarifying. I just realised this issue was created before the readOnly dimming change, so #182 is a separate render-crash fix than the root cause here.