using gvim as editor on Windows

I'd prefer to use gvim as an editor on Windows XP instead of vim. (I also
prefer it as a difftool, but that's a separate issue.) Gvim releases
the terminal when it launches, which git doesn't like too much. So I
create gvimf.cmd in my path and use it for core.editor. Gvimf.cmd is
quite simple; it calls:
	start "dummy" /b /wait "C:\Program Files\Vim\vim72\gvim.exe" %*

In .gitconfig:
[core]
	editor = gvimf.cmd

This works well enough for git commit. However, git rebase -i is not
happy. It errors:
	C:\path to\repo> git rebase -i HEAD~10
	The system cannot find the file dummy.
	Could not execute editor

Okay, I can fix that. I change core.editor to "cmd \\/c gvimf.cmd". (This
is the same pattern I use for gvim as a difftool.) Now my .gitconfig has:
[core]
	editor = cmd \\\\/c gvimf.cmd

Git rebase is happy, but git commit is not. It errors:
	C:\path to\repo> git commit
	'OMMIT_EDITMSG' is not recognized as an internal or external command,
	operable program or batch file.
	error: There was a problem with the editor 'cmd \\/c gvimf.cmd'.
	Please supply the message using either -m or -F option.

In the selfish hope to avoid work, has anyone else already encountered and solved how to use gvim as an editor?

Tait

On Fri, Mar 5, 2010 at 23:06, Tait <git.git@t41t.com> wrote:

Use the -f (stay in the foreground) flag. I haven't tried this in Windows, but that's how I've used it in Linux.

[core]
    editor = gvim -f

On Windows, gvim -f is basically a shortcut for the start invocation I pasted above. It works well enough for commit, but not for rebase (or alternately, for rebase -- so long as it doesn't open an editor for git commit -- but not commit).

Tait

Tait, 2010-03-06 08:37:

Not necessarily. You can avoid using the .bat wrappers from C:\Windows, which cause the problem, but use gvim.exe directly by setting your PATH appropriately. It will also work for git-difftool.

Markus

I was hoping for a little more life in this thread.

Does calling the .exe directly work for you? If I call gvim.exe directly (with or without -f -- it doesn't matter), it opens a new file called $@. After quitting, the commit is aborted for lack of a commit message. I can do an ugly work-around by making core.editor "gvim.exe -f $@" but then gvim opens two buffers, one for the commit message and another for the literal $@.

With rebase -i, calling the executable directly (with or without -f) works to open the commit list. Rebase -i with $@ in the setting fails. It appears the filename is not quoted correctly and vim is opening multiple buffers with various components of the path name as filenames.

The problem seems to be unique to me, so I'll find some time to look at what rebase and/or commit are doing wrong.

Tait

Tait, 2010-03-08 19:54:

First of all: do you have the problems in cmd.exe or Git Bash or both?

I don't know where the $@ should come from. You apparently don't invoke gvim.exe directly. git-commit is a C program, not a shell script, there should come no $@ from this side. What does invoking gvim.exe on the command line without the use of git do?

I have: core.editor=gvim -f C:\Programme\Vim\vim72 in PATH (both before or after C:\WINDOWS works here) Works with cmd.exe and Git Bash.

I guess neither rebase nor commit are wrong in this case.

Markus

cmd.exe

I've never used git bash until now, but the behavior is the same there.

It comes from line 33 of editor.c, in launch_editor().
if (strcmp(editor, ":")) {
    /* ... */
    if (strcspn(editor, "$ \t'") != len) {
        /* there are specials */
        strbuf_addf(&arg0, "%s \"$@\"", editor);
        args[i++] = "sh";
        args[i++] = "-c";
        args[i++] = arg0.buf;
    }
    args[i++] = editor;
    args[i++] = path;
    args[i] = NULL;
    /* ... */
}

It looks like this was added to detect EDITOR=: but it also manages to catch Windows paths. I'm not familiar with the EDITOR=: convention. What is that supposed to indicate? Can we narrow the detection to that specific case, or does a : anywhere in EDITOR need to be handled this way?

Rebase doesn't use launch_editor, instead just calling the editor directly. Coming up with a combination of quoting and escaping that can pass both cases will be difficult or impossible.

It appears that e97c9a removed the code above from editor.c, but it's still present in prepare_shell_cmd() with even more legal filename characters like = and ;.

Thanks for the help Markus.

Tait

Tait <git.git@t41t.com> writes:

This says "if 'editor' is not exactly the string ':'", then come into this block. If you set editor to ":abc", or "c:\path to\my editor.exe", they are not "exactly the string ':'" and the codepath inside will be executed.

Literally, it means "run ':' command as the editor". ':' command takes and ignores arbitrary arguments and returns success without doing anything. As such, the codepath pretends that it ran ':' command without actually running it, and returns as if it ran ':' command that left the input file given as its argument unmodified.

No, and the if statement is already narrow enough. I think the problem is that you have a broken shell ("sh").

    /* ... */
    if (strcspn(editor, "$ \t'") != len) {
        /* there are specials */
        strbuf_addf(&arg0, "%s \"$@\"", editor);
        args[i++] = "sh";
        args[i++] = "-c";
        args[i++] = arg0.buf;
    }
    args[i++] = editor;
    args[i++] = path;
    args[i] = NULL;
    /* ... */

If you have editor='"c:\some path\editor" -f', strcspn() notices that you have a funny character in the path, and creates this string in arg0:

    "c:\some path\editor" -f "$@"

and feeds '-c', the above arg0, editor, and finally the name of the file, to your shell; it is the same as running this from the command line:

    sh -c '"c:\some path\editor" -f "$@"' '"c:\some path\editor" -f' path-to-file

Now shell is supposed to expand "$@" into positional parameters, i.e. $1 (in this case, path-to-file) and run the named editor with it, IOW, your editor program should see "-f" as its first parameter, and path-to-file as its second parameter (and argv[] is terminated with NULL after that).

If you end up with a file whose name literally is '$@', that probably means your "sh" did not expand it correctly.

Oh right; I ... yeah, something. (I've got no excuse for mis-thinking that one.)

It does expand the $@ when I add it explicitly to core.editor though. Maybe it's the ""s. I'll have to figure out how to compile git for Windows to try a patch.

Oddly enough, if I remove the : from the file path, it does work as expected. Adding the : back introduces the faulty behavior described earlier.

Tait

Tait schrieb:

Which : are you talking about?

-- Hannes