Closed lervag closed 4 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 thewinhighlight
option in thewo
table, but it seems this is always reset?
Ah, it seems it comes from here:
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?
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.
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.
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.
I just pushed a fix for opening folds after jumping (preview was already fixed). Would be great if you can confirm!
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?
It should already do that for preview. Are you using any fold plugins like ufo or something?
Huh, ok. It seems you are right. Sorry. The preview does not have any closed folds.
The reason I was confused is this:
p
, the preview displays more or less as expected.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:
p
starts preview for entry under cursor.To get this exact behavior, you can just toggle auto preview with P
.
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.
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
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 thewinhighlight
option in thewo
table, but it seems this is always reset?Steps To Reproduce
-- vim: fdm=marker
as a modeline) and add some folds with-- {{{1
.:Trouble lsp focus=true
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