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

Compatibility with folding #28

Closed
giuseppelettieri opened this issue Jan 26, 2024 · 4 comments · Fixed by #29
Closed

Compatibility with folding #28

giuseppelettieri opened this issue Jan 26, 2024 · 4 comments · Fixed by #29

Comments

@giuseppelettieri
Copy link

giuseppelettieri commented Jan 26, 2024

Thank you for this really useful plugin. However, I am getting confusing results when folding is enabled. I think that the :g commands don't look inside the folds, so they may delete unintended lines when the diff markers somehow end up inside a fold. I have solved the issue by adding silent execute "normal! zR" and silent execute "normal! zM" around the delete commands, but I am no vimscript expert by any means and I guess there should be a better way.

@whiteinge
Copy link
Owner

whiteinge commented Jan 27, 2024

Hi! I'm glad you like it and thanks for the report. I need a bit more information, or perhaps a way to reproduce the problem, because that raises questions for me:

  1. Folds are entirely cosmetic and shouldn't affect :g at all, so it's interesting that showing/hiding folds solves the problem for you -- I wonder if something is causing the diffconflicts commands to get run at the wrong time or on the wrong buffer and folding is having some affect on that.

    Can you think of any plugins or autocommands in your config that may reposition the cursor when creating splits or new buffers, possibly for specific filetypes?

  2. What kind of folding is affecting that file? Vimdiff functionality usually(?) turns on diff folding to hide everything but the conflicts. I wonder if some kind of filetype-specific folding is taking precedence and causing trouble.

    If it's filetype-specific you might be able to see different behavior with a different kind of file. You can try the text file attached below by opening it directly then running :DiffConflicts once it's open. Does it behave the same broken way or not?

poem.txt

@giuseppelettieri
Copy link
Author

Hi @whiteinge , thanks for the reply. I have moved away my ~/.vim directory and tried with a clean vim as distributed in Ubuntu 23.04 (2:9.0.1000-4ubuntu3.3). I can reproduce the effect with the following small file

void f() {
<<<<<<< A
        x++;
=======
        x--;
>>>>>>> B
}
<<<<<<< C
int y;
=======
double y;
>>>>>>> D
int z;

I load the file, set its filetype to C, and then set foldmethod=syntax. The f() function gets folded, hiding the diff markers inside it. Now I run :g/^<<<<<<< /,/^=======\r\?$/d and this is the result:

void f() {
double y;
>>>>>>> D
int z;

It looks like vim saw the <<<<<<< inside f(), but then missed the first ======= and went straight to the second one. If I open the folds before running :g I get the expected result:

void f() {
        x--;
>>>>>>> B
}
double y;
>>>>>>> D
int z;

It looks like a bug in vim to me, since it is inconsistent in what it sees or doesn't see.

whiteinge added a commit that referenced this issue Jan 29, 2024
If `foldmethod=syntax` it somehow affects the contents the deletes will
operate on. No idea why. Running `diffthis` will set `foldmethod=diff`
so if we do that before making the edits we should avoid the problem.

Closes #28
@whiteinge
Copy link
Owner

Thanks, those steps are great and I can reproduce it now. Very strange result -- I've never seen folds affect an operation like that. You may be right about it being a bug.

Will you give the PR above a try? In my testing it side-steps the bug by overriding any foldmethod value before the edits are attempted.

@giuseppelettieri
Copy link
Author

Will you give the PR above a try? In my testing it side-steps the bug by overriding any foldmethod value before the edits are attempted.

yes, it seems to be working

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

Successfully merging a pull request may close this issue.

2 participants