Closed Frydac closed 2 years ago
It's limilition of foldmethod=manual
which is driver level issue. I can provide the API like zR
and zM
as a workaround.
Oh ok, thanks for the info, I see now that it is in the README.md under Usage (my bad.. sry) I didn't understand it when I read it, I guess I needed the above example/experimentation to understand vim folds a bit better to understand the issue.
If you ever decide to tackle this, I would definitely appreciate it.
I do think this is already such a cool plugin, the syntax highlighting in the folds are an absolute game-changer for usability, the main reason I didn't like folds before, and should be part of core (neo)vim imho. Great work, thanks!
It's the duplicate of https://github.com/kevinhwang91/nvim-ufo/issues/49. I read this issue from my cell phone roughly just now.
The new API only changes virtual foldlevel
, the actual foldlevel
will never change. Do you think it's worthwhile? I'm not clear your workflow, but zo
, zO
, zc
, zC
, zR
and zM
work fine with me.
I do think this is already such a cool plugin, the syntax highlighting in the folds are an absolute game-changer for usability, the main reason I didn't like folds before, and should be part of core (neo)vim IMHO.
The core is hard to imp syntax fold, I have read the source code so I release this plugin. ufo is the best solution for neovim fold AFAIK, never block, extremely fast.
It's the duplicate of #49. I read this issue from my cell phone roughly just now. The new API only changes
virtual foldlevel
, the actualfoldlevel
will never change. Do you think it's worthwhile? I'm not clear your workflow, butzo
,zO
,zc
,zC
,zR
andzM
work fine with me.
yes, zo
, zO
, zc
, zC
, zR
and zM
have the intended effect.
However, zr
and zm
work with the actual foldlevel
(afaik), they have an effect: they set the actual foldlevel and the folds close or open accordingly, but they also cause 2 issues in my experience:
zr
and zm
, then the actual foldlevel can get smaller than the highest foldlevel of the buffer, any fold the user opens that has a higher level than the current actual foldlevel (e.g. with zO
) will autoclose when editing (because of the foldmethod=manual limitation iirc). I think that the person of #49 maybe didn't notice this? Or maybe I'm wrong somehow?zr
and zm
don't have the same behavior when used after zR
and zM
(as I tried to explain in the 3 bulletpoints in my original post).
zR
will close all folds and set foldlevel to 0, then zm
will open 1 foldlevel and set foldlevel to 1.closeAllFolds
: first zR
will close all folds and foldlevel remains 99, then zm
opens all folds to the highest foldlevel and the actual foldlevel will be set to the highest foldlevel. (I would like to be able to open all folds one level at a time after using zR
, which I don't think is possible now)These issues makes zr
and zm
not useful anymore imho.
I don't fully understand how folds and ufo work, but maybe the solution could be that zm
and zr
also get mapped to API functions that work with the virtual foldlevel
and don't depend on or change the actual foldlevel
?
Yes, zr
and zm
make non-sense if using ufo, I want to know the workflow why ufo needs to be compatible with native zr
and zm
which is hard to imp in ufo.
From example 2 you provided, I think you need to change the virtual foldlevel
to a specified level, like type v:count z your_key
. For now, 0
for closeAllFolds
and max
for openAllFolds
. This feature is not hard to imp, but incremental action like native zr
and zm
are not, because ufo don't maintain the virtual foldlevel
and no way to maintain it correctly.
I tried to make a video of the main usecase I use this for, it is not a super important usecase, but I do encounter it regularly in my work, and I seem to default to this behavior.
I added some pseudo C++ code where there are 2 nested namespaces then it has a few classes with a bunch of functions, these functions live at the same foldlevel, but are in different parent folds. This is the condition where this usecase is most effective imo, things at the same foldlevel but in different parent folds.
Without moving the cursor I can close all the folds zR
, then use a few zm
to open a few levels of folds until the functions of both classes become easily visible.
https://user-images.githubusercontent.com/2588526/183250481-de2f3606-c21a-4b08-97b0-98abc128c393.mp4
Doing this without zm
takes more keystrokes to accomplish.
I've been experimenting a bit, and it seems that it is possible to make a visual selection and then do open fold zo
, something like ggvGzo
which accomplishes similar behavior to the above usecase, and might make a usable mapping for zm
for this usecase. ggvGzc
doesn't work as expected though, it closes the top fold, and after that ggvGzo
also doesn't work like that anymore, but a zM
and then restarting does work. Not the same, but at least better than going to each class and opening it until I can see the functions.
vim.keymap.set('n', 'zm', require('ufo').closeFoldsWith, {})
eg. zm
, 1zm
, 2zm
and so on.
1zm
is extremely useful for methods in a class. Thank you for pushing me.
Neovim version (nvim -v | head -n1)
NVIM v0.7.2
Operating system/version
Manjaro Linux (updated yesterday)
How to reproduce the issue
cat mini.lua
nvim --clean -u mini.lua
do do do -- line 1 -- line 2 end end end