bug v3: preview with main window should open folds

[lervag]

Did you check docs and existing issues?

• [X] I have read all the trouble.nvim docs
• [X] I have searched the existing issues of trouble.nvim
• [X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

v0.10.0-dev-2754+g12240600f5

Operating system/version

Arch Linux

Describe the bug

When I open e.g. the symbols or lsp mode in a file where I have folds, the preview will not open/adjust the folds. I believe this can be fixed by including the window option foldenable = false somewhere, but I'm not exactly sure where.

Notice, I can fix this locally through configuration with

    opts = {
      preview = {
        type = "main",
        wo = {
          foldenable = false,
        },
      },
    -- ...

An additional question: I notice that the entire background of the main view is changed on the preview. Do I understand correctly that this is because the main type of the window is really a floating window in disguise? I tried changing it with the winhighlight option in the wo table, but it seems this is always reset?

Steps To Reproduce

1. Use standard/default settings.
2. Open e.g. som Lua file.
3. Enable folds; e.g. based on markers (for instance with -- vim: fdm=marker as a modeline) and add some folds with -- {{{1.
4. Open the lsp view with :Trouble lsp focus=true
5. Notice while navigating that the preview will adjust the main files location, but it will not adjust any folds.

Expected Behavior

I believe the expected behaviour would be to adjust folds e.g. with the zv mapping. Or possibly just disable folds for the preview itself.

Repro

No response

[lervag]

An additional question: I notice that the entire background of the main view is changed on the preview. Do I understand correctly that this is because the main type of the window is really a floating window in disguise? I tried changing it with the winhighlight option in the wo table, but it seems this is always reset?

Ah, it seems it comes from here:

https://github.com/folke/trouble.nvim/blob/10eff94809ecd6ee6cc59f42e9521b9b8a14e9ce/lua/trouble/view/window.lua#L148-L153

I believe, if winhighlight is empty, then it will use a default of Normal:NormalFloat or something like that for floating windows? I'm curious if the hardcoded value therefore should be something like Normal:Normal instead? Or, at least somehow make it configurable - i.e., don't set it to "" if it is already set by the provided opts table?

[folke]

Both issue should be fixed now.

In Trouble v2, the actual main window was used to show the preview buffer, but this could lead to all sorts of weird issues.

In v3, I indeed create a fake floating window on top of the main window.

[lervag]

Thanks! It's more or less fixed now - although one thing is still missing (for me). Both the preview, and the navigation with <cr> on an entry in the :Trouble lsp focus=true view will not adjust the folds. That is, given some file that has folds, I would expect the the preview would use something like zv to ensure that the folds are open at the previewed location. Similarly, when I activate a position with <cr>, I would expect that zv is used after navigating to the location.

I would not mind if this is configurable and "default off", although I would argue that, at least for previewing, opening folds seems like the expected behaviour.

[lervag]

I think, for the <cr> key map, it may be relatively easy to just write a custom action. I'm looking into that now. But the preview seems less straightforward.

[folke]

I just pushed a fix for opening folds after jumping (preview was already fixed). Would be great if you can confirm!

[lervag]

Yes, it seems to work very well and perfectly to my preference; thanks! Would it be possible to have this type of behaviour also for the preview feature?

[folke]

It should already do that for preview. Are you using any fold plugins like ufo or something?

[lervag]

Huh, ok. It seems you are right. Sorry. The preview does not have any closed folds.

The reason I was confused is this:

• I have autopreview off.
• When I click p, the preview displays more or less as expected.
• While still inside the Trouble window, I navigate to another entry and press p again. I expected the preview to update to the new location, but instead, the preview is closed and I'm again seeing the original view - which in my case was mostly folded. And that's what confused me.

I can see why we might want p to "toggle" the preview, but I would propose a slight change of behaviour:

• If no preview, then p starts preview for entry under cursor.
• If preview exists and we are already previewing the cursor entry, then we disable preview (same behaviour as now).
• If preview exists but cursor is on a different entry, then we instead update the preview to the new entry.

[folke]

To get this exact behavior, you can just toggle auto preview with P.

[lervag]

To get this exact behavior, you can just toggle auto preview with P.

Well, yes, that's almost right. I don't really like the auto preview. But fair enough, let's leave it at that. If it becomes too much of an itch I can try and make my own p mapping.