E749: empty buffer with vimdiff startup commands

1,086 views
Skip to first unread message

François-Xavier Thomas

unread,
Jan 8, 2016, 9:16:54 PM1/8/16
to vim_use
Hello all,

I've hit a small issue today. The following sequence always stops a few seconds on 'E749: empty buffer' before displaying the diffs. Calling '1bufdo set ma' afterwards does not trigger the error.

echo "base text" > base
echo "branch a" > local
echo "branch b" > remote
echo "branch a" > merged
vimdiff -f -d -c 'wincmd J' -c 'bufdo set noma' -c '1bufdo set ma' merged local base remote

Does anyone has an idea about why this is happening and how I can fix it?

My guess is that '-c' happens after the first file is loaded (according to vimdiff --help) but, I suppose, somewhere before local, base and remote are fully loaded. Am I right?

I'm trying to make the 4-way split in 'git mergetool' properly answer to 'dp' from one of the top windows. After reading the help, I'm trying to automatically set the local, remote and base files as non-modifiable so that the remaining (merged) buffer becomes the default 'dp' target. If there is a better solution than what I'm doing, I'd love to hear about it!

Thanks a bunch,
François-Xavier

Nikolay Aleksandrovich Pavlov

unread,
Jan 8, 2016, 9:41:35 PM1/8/16
to vim...@googlegroups.com
​I do not know why this happens, but I would really suggest to always avoid :bufdo.​ First, this command switches current buffer which is not wanted 99% of times. Second, it has strange interactions with at least my setup which results in absence of syntax highlighting (basically why I never use it). Third, 90% of times one is using :bufdo switching buffers is not needed at all. Specifically in your case I would use

    vimdiff -f -c 'wincmd J' -c 'call map(range(1, bufnr("$")), "setbufvar(v:val, \"&modifiable\", v:val == 1)")' merged local base remote

Alternative solution is to simply remap `dp` so it will put to first buffer always.

Note that -d is not present: Vim will start diff mode once executable is called vimdiff, thats the whole point of such naming (usually vimdiff is a simple sym- or hardlink to vim, if in your distribution it is not then maintainers are probably insane).

---

And please do not use short versions of option names when asking for help, I have no idea WTF is ma option. It is also good for documentation purposes.

 

Thanks a bunch,
François-Xavier

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

François-Xavier Thomas

unread,
Jan 9, 2016, 8:22:52 AM1/9/16
to vim_use
On Saturday, January 9, 2016 at 3:41:35 AM UTC+1, ZyX wrote:
> ​I do not know why this happens, but I would really suggest to always avoid :bufdo.​ First, this command switches current buffer which is not wanted 99% of times. Second, it has strange interactions with at least my setup which results in absence of syntax highlighting (basically why I never use it). Third, 90% of times one is using :bufdo switching buffers is not needed at all. Specifically in your case I would use
>
>
>     vimdiff -f -c 'wincmd J' -c 'call map(range(1, bufnr("$")), "setbufvar(v:val, \"&modifiable\", v:val == 1)")' merged local base remote

Thanks, this is exactly what I was looking for :)

I did notice that Vim was switching buffers when I used bufdo, but did not find an easy alternative command that did not, and my Vimscript knowledge simply isn't that good yet.

> Alternative solution is to simply remap `dp` so it will put to first buffer always.

True, although I'm not exactly sure it would do the right thing with other uses of diff buffers, e.g. I have multiple buffers open and call 'Gdiff' (from Fugitive, opens a diff from a given commit).

> Note that -d is not present: Vim will start diff mode once executable is called vimdiff, thats the whole point of such naming (usually vimdiff is a simple sym- or hardlink to vim, if in your distribution it is not then maintainers are probably insane).

I actually copy-pasted this from https://github.com/git/git/blob/master/mergetools/vimdiff and did not modify it since I assumed it was there for a reason.

> And please do not use short versions of option names when asking for help, I have no idea WTF is ma option. It is also good for documentation purposes.

Noted!
Reply all
Reply to author
Forward
0 new messages