On Mo, 05 Mär 2018, Axel Bender wrote:
> I use gvim as git's difftool, defined via .gitconfig as
>
> gvim -d "LOCAL" "REMOTE"
>
> From time to time new local files are created or old local files are deleted.
> In the latter case (or when new remote files are introduced), git would call
> gvim like so:
>
> gvim -d "nul" "<existing_file>"
>
> which (independent of the opendevice setting) results in gvim getting stuck
> on the first file - having the special name "nul".
I cannot reproduce this. Is there a plugin interfering?
Is this git-for-windows with a Windows compiled gvim? Or does
git-for-windows come with its own gvim?
>
> In the opposite case, git would call gvim like so:
>
> gvim -d "<existing_file>" "nul"
>
> successfully open the existing file, and not fail on the special file (name)
> "nul", which is a pretty inconsistent behavior...
>
> As the LOCAL and REMOTE variables cannot be arbitrarily swapped, I had hoped
> to use e.g. an autocmd with BufReadCmd to filter any special file names,
> replacing them as needed, but it seems, that already at this point the list
> of file names can no longer be changed.
>
> Is there hope?
It should be possible to use a BufReadCmd autocommand to workaround the
issue. However, I cannot reproduce it.
Best,
Christian
--
Beim Liebesspiel ist es wie beim Autofahren. Die Frauen mögen die
Umleitung, die Männer die Abkürzung.
-- Jeanne Moreau
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
