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

Problem with folds #25

Open
hcgraf opened this issue Feb 7, 2017 · 8 comments
Open

Problem with folds #25

hcgraf opened this issue Feb 7, 2017 · 8 comments

Comments

@hcgraf
Copy link
Contributor

hcgraf commented Feb 7, 2017

Hi,

when working with this (btw. very great) plugin and very big files, I found the following bug:
Because my blocks to compare are very long, it's convenient to fold them first and then do the Linediff.
That causes Linediff to remove the end of the file (i.e. after the second block).

I'll do a step by step example:

  • Open vim with an empty buffer. Type / paste the following code:
def one
  two
end

def two
  three
end

something at the end of the file
  • Fold the two blocks of codes (vim ex commands):
:1,3fold
:5,7fold
  • Select each block for Linediff (the cool thing is, this works with V on the closed fold!):
:1,3Linediff
:5,7Linediff
  • Change something in the second (right) diff-buffer, and save it

Result (at least for me):

  • The change is correctly copied to the original buffer (that's good)
  • The fold is gone (that's not perfect but ok)
  • The text after the second fold is gone (that's the bug ;-) )
@AndrewRadev
Copy link
Owner

Thank you for the detailed bug report, I really appreciate the example.

Unfortunately, I can't seem to reproduce the issue :/. My guess is that there's some setting that I have that's making the difference. Could you show me your .vimrc? I might be able to find the setting like that. Let me know what your Vim version is as well, just in case.

@hcgraf
Copy link
Contributor Author

hcgraf commented Feb 7, 2017

Thank you for your fast reply!
You're right, with a minimal vimrc, it doesn't occur.
My vimrc is quite big and a lot of plugins, so I don't want you to work through all of that ;)
I'll do my own investigations and I'll report back if I find the culprit!

Thanks anyway!

@AndrewRadev
Copy link
Owner

It's likely that it's a setting and not a plugin, because i can't think of any plugin that could affect this one. If you manage to narrow it down to whatever setting is causing this, do let me know. There might be something I could do on the plugin side to prevent people from being affected by it.

@hcgraf
Copy link
Contributor Author

hcgraf commented Feb 7, 2017

Ok, I think I tracked it down, it was quite a tough one ;)

It happens only if

The Nerd-Tree-Tabs plugin which tries to make a NerdTree buffer persistent over all tabs. It's probably a quite hacky abuse of the way vim handles buffers/tabs, so that's probably the reason it interferes here :(

OK, at least I have a workaround now (just close Nerdtree).
But of course, if you want to have a closer look at it and find a proper solution (or maybe a bug in NerdtreeTabs), that would be even better :)

@hcgraf
Copy link
Contributor Author

hcgraf commented Feb 7, 2017

OK now again with automatic testcase with minimal vimrc, so it should be reproducible independently of the environment.

vimrc

set nocompatible
filetype off
set runtimepath=~/.vim/bundle/linediff.vim/
set runtimepath^=~/.vim/bundle/nerdtree/
set runtimepath^=~/.vim/bundle/vim-nerdtree-tabs/
filetype plugin indent on 

test.txt

def one
  two
end

def two
  three
end

something at the end of the file

script.vim

NERDTreeTabsOpen
" move the cursor out of the NERDTree buffer
winc l
1,3fold
5,7fold
1,3Linediff
5,7Linediff
" change something in the right diff buffer
winc l
normal ciwabc
w
" back to the original test.txt buffer
normal gt
/something
  • run the command in this folder: vim -u vimrc test.txt -c 'source script.vim'

You have reproduced the bug, if you get an error message saying that 'something' was not found.
By commenting the first line in script.vim 'something' is found.

@AndrewRadev
Copy link
Owner

Okay, I've managed to reproduce it, and I think the key is the setting g:nerdtree_tabs_synchronize_focus. If I set it to 0, the issue doesn't seem to happen. My guess is that, when I switch around buffers, an autocommand catches the event and switches to the NERDTree instead. I can't really think of how I could fix this on my end, to be honest, but if this setting works, it might be the simplest way to avoid this happening.

@xaizek
Copy link
Contributor

xaizek commented Mar 8, 2017

@AndrewRadev, see :help autocmd-disable. There are 'eventignore' and :noautocmd. Sounds like they might be useful here.

@AndrewRadev
Copy link
Owner

Thanks, @xaizek, it might be something to experiment with. I'm not sure it'll work, since I think it's autocommands that get triggered outside the plugin that do this. Still, it's something to try.

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

3 participants