Feature: nvim-treesitter-context in previewer [DONE]

[ibhagwan]

Have you RTFM'd?

• I have done proper research

Feature Request

Ref: #1485, #1509

Enabled by default with the below options

require("fzf-lua").setup({
  previewers = { builtin = {
    -- See https://github.com/nvim-treesitter/nvim-treesitter-context for more options
    -- Set `context=true` to use whatever options used in your `nvim-treesitter-config` setup call
    treesitter = { context = { max_lines = 1, trim_scope = "inner" } }
  } }
})

Can also be set per call:

Note that flag "path" for a call is previewer.treesitter.context

:FzfLua live_grep previewer.treesitter.context=true
:FzfLua live_grep previewer.treesitter.context={max_lines=2,trim_scope="outer"}

Or with lua:

:lua require("fzf-lua").live_grep({ previewer = { treesitter = { context = true } } })
:lua require("fzf-lua").live_grep({ previewer = { treesitter = { context = {max_lines=2,trim_scope="outer"} } } })

[ibhagwan]

5038142

@xzbdmw I think I nailed it, no need to configure multiwindow or zindex as the code will temporarily set the required values for the lifetime of the fzf-lua window, seems to work pretty nice.

I couldn't figure out one thing, when first calling update on the new buffer the context refuses to show unless I scroll or switch to another entry within the same buffer, this seems to be solved by wrapping the update call with vim.schedule which is somehwat of a hack as it's not needed as we're not inside a vim.fastevent, but as long as it works I'm fine with it as the "integration" is a hack to begin with due to the lack of official API.

Add this to your setup call to enable (modifying the params of the "builtin" previewer):

require("fzf-lua").setup({
  previewers = { builtin = { treesitter = { context = true} } }
})

Or individually:

:FzfLua live_grep previewer.treesitter.context=true

Let me know what you think?

[xzbdmw]

Yes, it works for me, the reason you need some defer probably is that it is throttled(not that sure, it seems calling open() directly bypass the throttle mechanism), but schedule may not be enough, since the default throttle time is 150ms , a more reliable/hacky way is calling update() multiple times with defer_fn({0ms,10ms,100ms,200ms}), the cost of update() is very low.

[ibhagwan]

Yes, it works for me, the reason you need some defer probably is that it is throttled, but schedule may not be enough, since the default throttle time is 150ms , a more reliable/hacky way is calling update() multiple times with defer_fn({0ms,10ms,100ms,200ms}), the cost of update() is very low.

I used defer_fn first but as I saw it was working with 0 delay I switched to schedule, I’ll improve the “hack” tomorrow and also add an optional key bind to toggle the context on/off while the preview is open.

[xzbdmw]

Ok, I know the problem, when you call open() without defer, it indeed succeeds, the window opens, but some autocmds triggers update_single_context, it then checks cannot_open, but because the direct call to open(), attach[bufnr] will return false, causing the newly opened window to be immediately closed.

Comment out OptionSet and WinResized turned out to solve the defer hack.

While attach is a local variable, it seems we have no workaround for that, using defer_fn({0ms, 10ms, 100ms, 200ms}) still seems to be the easiest solution. Or, find a way to trigger the BufReadPost, so previewer buffer is added to attach.

[ibhagwan]

Ok, I know the problem, when you call open() without defer, it indeed succeeds, the window opens, but some autocmds triggers update_single_context, it then checks cannot_open, but because the direct call to open(), attach[bufnr] will return false, causing the newly opened window to be immediately closed.

Comment out OptionSet and WinResized turned out to solve the defer hack.

While attach is a local variable, it seems we have no workaround for that, using defer_fn({0ms, 10ms, 100ms, 200ms}) still seems to be the easiest solution. Or, find a way to trigger the BufReadPost, so previewer buffer is added to attach.

I tried using vim.o.eventignore = "all" but it didn't work, so it looks like this is currently the best way?

I didn't look explore the treesitter-context code deeply, what are the chances that a single call to vim,schedule doesn't show the window? It seemed to work pretty consistently for me with a single vim.schedule, perhaps on a slow machine?

I also added 2 more treesitter-context life-cycle options which IMHO are much nicer when it comes to the preview window, this makes it so there's less clutter when the context contains inner conditions and other nonsense, I believe what most users would care about is the calling function:

max_lines = 1, -- How many lines the window should span. Values <= 0 mean no limit.
trim_scope = 'inner', -- Which context lines to discard if `max_lines` is exceeded. Choices: 'inner', 'outer'

fc220ec

[xzbdmw]

what are the chances that a single call to vim,schedule doesn't show the window

If OptionSet/WinSrolled is guaranteed to triggered first, then it is scheduled to close any unattached window, after that, fzf-lua calls update, also scheduled, avoid the potential closing, there is no problem; on the flip side, if fzflua calls update() first, it will be closed by a later OptionSet/WinSrolled trigger, that's why it must be deferred by a schedule now. The order is not clear to me though.

[ibhagwan]

what are the chances that a single call to vim,schedule doesn't show the window

If OptionSet/WinSrolled is guaranteed to triggered first, then it is scheduled to close any unattached window, after that, fzf-lua calls update, also scheduled, avoid the potential closing, there is no problem; on the flip side, if fzflua calls update() first, it will be closed by a later OptionSet/WinSrolled trigger, that's why it must be deferred by a schedule now. The order is not clear to me though.

Perhaps we can leave one defer call with a timeout of 0 (equivalent to a single vim.schedule) and also enable this option by default - this will be the only way to get true feedback :)

If the single call fails, we can restore to multiple timely delayed calls.

[xzbdmw]

Yeah, I think it can be enabled by default, maybe defer_fn(10)? The race possibility is going to decrease a lot.

[ibhagwan]

Yeah, I think it can be enabled by default, maybe defer_fn(10)? The race possibility is going to decrease a lot.

You’re probably right, although I’d still prefer to have a call with 0 delay so it appears to display instantaneously, I’ve compromised on 2 calls with delays of 0, 20ms respectively and enabled by default.

617383a

[xzbdmw]

this is a new function added a month ago, open, get, close exits for over one year, maybe we should be very conservative for their existence, actually I test my treesitter-context fork in March's commit, and it works too, except the call to close_leaked_window, we can simply delete this line, check if open, get, close exists, only so, enable it successful.

max_lines = 1, -- How many lines the window should span. Values <= 0 mean no limit.
trim_scope = 'inner', -- Which context lines to discard if max_lines is exceeded. Choices: 'inner', 'outer'

For languages like java or rust, method lives inside impl or class keyword, maybe we can expose these settings to users.

[ibhagwan]

this is a new function added a month ago, open, get, close exits for over one year, maybe we should be very conservative for their existence,

I thought about it too, but I believe someone updating fzf-lua will also update treesitter-context.

For languages like java or rust, method lives inside impl or class keyword, maybe we can expose these settings to users.

I will make the context var accept a table which will act as the treesitter context config.

I’m going to give this a while to collect feedback and make the changes, I’m pretty sure users will also want the toggle keybind.

[ibhagwan]

@xzbdmw, 1a3c312

The defaults are:

  context = { max_lines = 1, trim_scope = "inner" }

Set context=true to use whatever defaults you have setup original for nvim-treesitter-context.

Can also setup temporarily in one call, e.g.:

:FzfLua live_grep previewer.treesitter.context={max_lines=2,trim_scope="outer"}

[ibhagwan]

c40666b added a new action toggle-preview-ts-ctx by default bound to <F7> and customizable via keymap.builtin.

Unless I'm missing something this feature is pretty much complete.

[TheLeoP]

c40666b removed the ["ctrl-q"] = "select-all+accept", keymap from the telescope profile. Was this intentional or an oversight when modifying all of the keymaps?

[ibhagwan]

c40666b removed the ["ctrl-q"] = "select-all+accept", keymap from the telescope profile. Was this intentional or an oversight when modifying all of the keymaps?

Unintentional, while searching for keymap in profiles (due to adding of F7) I changed the profile keymap to inherit from defaults (thus deleting all defaults), this was one a mistake.

[ibhagwan]

@TheLeoP 498459c

[TheLeoP]

Thanks @ibhagwan :D

[ibhagwan]

2bc454b

With the addition of f7|f8 to increase/decrease the treesitter context max_lines, this feature is complete.