Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabling folding #11

Closed
GordianDziwis opened this issue Aug 8, 2018 · 10 comments
Closed

Disabling folding #11

GordianDziwis opened this issue Aug 8, 2018 · 10 comments

Comments

@GordianDziwis
Copy link

I guess this is kind of a feature request. But here is hacky workaround:

let g:wiki_mappings_global = {
    \ '<plug>(wiki-link-open)' : '<c>tttt',
    \}
nmap <LocalLeader>w <plug>(wiki-index):set nofoldenable<cr>
au FileType wiki nmap<buffer><cr> <plug>(wiki-link-open):set nofoldenable<cr>
@lervag
Copy link
Owner

lervag commented Aug 9, 2018

I'm sorry, but I don't quite follow. Could you please explain what you want to achieve?

@lervag
Copy link
Owner

lervag commented Aug 9, 2018

I never enable folds in this plugin, I just set the foldmethod. If you don't want folds, you can either disable them globally with set nofoldenable in your vimrc, or for wiki files with autocmd Filetype wiki set nofoldenable.

@GordianDziwis
Copy link
Author

I tried it with a minimal init.vim

set nocompatible              " be iMproved, required
filetype off                  " required
call plug#begin('~/.vim/bundle')
Plug 'lervag/wiki.vim'
call plug#end()
syntax on
filetype plugin indent on    " required

let g:wiki_root = '~/Cloud/wiki/'
set nofoldenable
autocmd Filetype wiki set nofoldenable

And the wiki is still folded. I thought it was the plugin, because the filetype stuff gets sourced after the init.vim

@lervag lervag closed this as completed in 26ada84 Aug 9, 2018
@lervag
Copy link
Owner

lervag commented Aug 9, 2018

Sorry, this was actually a bug. In the code that opens a wiki link, I do normal! zMzvzz to focus the link target, but zM enables folds. I was not aware. I've fixed this now.

@rattletat
Copy link

rattletat commented Mar 27, 2020

Hi @lervag, is it possible that you overwrite the foldlevel user option? Using the index command (and this Focusing part), foldlevel=0 is forced.

Maybe something like this would be better:

" Focus
  if &foldenable
    if l:same_file || &foldlevel > 0
      normal! zv
    else
      normal! zMzv
    endif
  endif

However, I'm not sure why you close all folds by default in the first place. Isn't it done automatically?

@lervag
Copy link
Owner

lervag commented Mar 27, 2020

Good questions.

However, I'm not sure why you close all folds by default in the first place. Isn't it done automatically?

No, not necessarily. That is, people could use different foldlevel settings. But I do agree that the current version overrides this!

Perhaps it is better to fully avoid the zM. People could use the autocmd event to customize if they want a different behaviour, after all.

I'd like more opinions on this. @jabirali for instance, what do you think?

Note: I've accepted your suggested change as a bugfix.

lervag added a commit that referenced this issue Mar 27, 2020
@jabirali
Copy link

jabirali commented Apr 4, 2020

Sorry about the late reply... I've been a lot sick lately, so haven't kept up with my notifications :).

I'd like more opinions on this. @jabirali for instance, what do you think?

Personally, I think I like the same behaviour as you: I like that folding allows me to only see the relevant parts of the file, and I believe the zMzv solution fits well with that workflow.

If you do keep this behaviour, perhaps the snippet of @rattletat can be generalized to all fold levels? Quickly checking the docs, it seems like replacing zMzv by zx is the most correct solution, and seems to be supported on both Vim and Neovim?

If you decide to remove the zM part, I think it could be nice to mention briefly how to set it up again in the documentation :).

@lervag
Copy link
Owner

lervag commented Apr 6, 2020

replacing zMzv by zx is the most correct solution

The docs for zx:

							*zx*
zx		Update folds: Undo manually opened and closed folds: re-apply
		'foldlevel', then do "zv": View cursor line.
		Also forces recomputing folds.  This is useful when using
		'foldexpr' and the buffer is changed in a way that results in
		folds not to be updated properly.

I'm not so sure if this is right, though. In the l:same_file || &foldlevel > 0 case, we don't want to disturb the manually changed folds, only to ensure that the current line is visible (i.e. zv). In the other case, we know that &foldlevel = 0, which means zx should behave the same as zMzv, right? Thus, this proposed change does not really change anything? Or did I miss something?

Or did you mean to change the entire snippet and do zx in all cases? I don't like that, because e.g. navigation inside the same file should not close other open folds.

Perhaps, though, that this is better (and what you meant)?

    if l:same_file
      normal! zv
    else
      normal! zx
    endif

Opinions, @rattletat and @jabirali?

If you decide to remove the zM part, I think it could be nice to mention briefly how to set it up again in the documentation :).

Agreed, will do that if I make the change.

@jabirali
Copy link

jabirali commented Apr 6, 2020

Indeed, that's what I meant :).

Having a different behavior for l:same_file is not the issue. I was mainly thinking that I like the current zMzv behaviour, but think it would be ideal if wiki.vim behaved roughly the same way for foldlevel=0 and foldlevel>0.

My understanding of the documentation is that replacing zMzv with zx allows you to handle all fold levels with the same code (as in the code snippet you posted), and provide a consistent behavior.

@lervag
Copy link
Owner

lervag commented Apr 6, 2020

Agreed, thanks. I'll update accordingly.

lervag added a commit that referenced this issue Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants