folke / trouble.nvim

🚦 A pretty diagnostics, references, telescope results, quickfix and location list to help you solve all the trouble your code is causing.
Apache License 2.0
5.45k stars 177 forks source link

bug v3: preview with main window should open folds #408

Closed lervag closed 4 months ago

lervag commented 6 months ago

Did you check docs and existing issues?

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 commented 6 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

lervag commented 4 months ago

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 commented 4 months ago

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

lervag commented 4 months ago

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

The reason I was confused is this:

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

folke commented 4 months ago

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

lervag commented 4 months ago

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.